Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home

GP4.3 - Growth and Fraud - Case #3 - Phishing
GP4.3 - Growth and Fraud - Case #3 - Phishing
GP4.3 - Growth and Fraud - Case #3 - Phishing
GP4.3 - Growth and Fraud - Case #3 - Phishing
GP4.3 - Growth and Fraud - Case #3 - Phishing
long-term GPG signing key
long-term GPG signing key
long-term GPG signing key
Kama Sutra Spoofs Digital Certificates
A glimpse of SIGINT 20 years ago
thoughts on one time pads
thoughts on one time pads
thoughts on one time pads
Face and fingerprints swiped in Dutch biometric passport crack (another card skim vulnerability)
thoughts on one time pads
thoughts on one time pads
serious threat models
Major Browsers and CAS announce balkanisation of Internet Security
"doing the CA statement shuffle" and other dances
"doing the CA statement shuffle" and other dances
FraudWatch - Chip&Pin, a new tenner (USD10)
FraudWatch - Chip&Pin, a new tenner (USD10)
FraudWatch - Chip&Pin, a new tenner (USD10)
FraudWatch - Chip&Pin, a new tenner (USD10)
NPR : E-Mail Encryption Rare in Everyday Use
FraudWatch - Chip&Pin, a new tenner (USD10)
FraudWatch - Chip&Pin, a new tenner (USD10)
Meccano Trojans coming to a desktop near you
Meccano Trojans coming to a desktop near you
Meccano Trojans coming to a desktop near you
Creativity and security
Creativity and security
Meccano Trojans coming to a desktop near you
Meccano Trojans coming to a desktop near you
FraudWatch - Chip&Pin, a new tenner (USD10)
4th April, 1984
Unforgeable Blinded Credentials
Meccano Trojans coming to a desktop near you
Creativity and security
FraudWatch - Chip&Pin, a new tenner (USD10)
FraudWatch - Chip&Pin, a new tenner (USD10)
FraudWatch - Chip&Pin, a new tenner (USD10)
Votes are coins stamped with the Red Queen's head
Votes are coins stamped with the Red Queen's head
Creativity and security
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

GP4.3 - Growth and Fraud - Case #3 - Phishing

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 3, 2006 11:54 AM
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
MailingList: Financial Cryptography
Daniel A. Nagy wrote:
Actually, I still don't understand why do domain name registries not provide certs with the domain name. After l, there's already a hierarchy of trust in place there, why have a different one (and why trust the other one to certify this one?)? What would be more authoritative certification than that of the registry?

ref:
https://www.financialcryptography.com/mt/archives/000609.html

one might conjecture that there are some economic forces in play ... if it was done within dns ... there wouldn't have been justification for independent business ... it would simply be part of the existing infrastructure.

the other part is if done within the existing dns operation, there would have been no justification for PKI, certification authorities, digital certificates, etc.

basically dns provides real-time authoritative information responses (and structured for generalized information not just binding of ip-address to domain name ... but can and does provide various kinds of other information binding including to domain name).

within the dns real-time authoriative information responses, a public key implementation would be bound to a domain name ... in addition to the other information bound to a domain name and provided in a real time response.

the digital certificate model was designed to provide relying party with stale, static binding information in stituations where the relying party had no access to their own local repository of information and/or online, real-time access to some authoritatve agency with the information (aka an offline environment)

there is dnssec effort, somewhat backed by the ssl certification industry to have domain name owners register a public key when a domain name is registered. currently, a certification authority requires some identification information in conjunction with an ssl domain name certificate. the ssl certification authority then can do a real-time retrieval of the identification information onfile with the domain name infrastructure. then the certification authority does the expensive, time-consuming, and error prone task of matching the supplied identification information with the onfile identification information.

dnssec would allow the certification authority to request digital signature on ssl domain name certificate applications. then the certification authority could do a real-time retrival of the onfile public key and verify the digital signature ... replacing a time-consuming, expensive, and error-prone identification matching process with a much simpler, reliable, and less-expensive authentication operation.

the catch-22, is if the ssl certification authority industry can start doing real-time retrivals of onfile public keys ... then the rest of the world could also ... obsoleting the requirement for ssl domain name certificates. lots of past postings on ssl certificates and the ssl certification process
http://www.garlic.com/~lynn/subpubkey.html#sslcert

i've even suggested a drastically simplified and efficient ssl hand-shaking protocol. the client does a call to dns just like they do today ... but if there is any registered public key ... they get back both the ip-address along with any public key and crypto protocol options piggy-backed on the ip-address response.

then in a single communication with the server, they could transmit the random session key (encrypted with the server's public key) and the actual request (encrypted with the random session key) ... no SSL protocol setup chatter is required.

this could even be done as a udp and/or transaction protocol.

note that SSL over HTTP over TCP is quite expensive. the minimum packet exchange for just TCP is seven packets ... and then HTTP and SSL has to ride on top of that ... including all the SSL protocol setup chatter.

an early reliable "transaction" protocol was VMTP ... which reduced the 7-packet minimum TCP to 5-packet minimum.

I did a lot of work on XTP ... which included support for reliable "transaction" protocol in 3-packet minimum exchange. lots of past posts on XTP
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

aka do dns udp in single round-trip, getting ip-address, public key, and any ssl crypto options in single roundtrip. then do ssl-like encrypted request/response transaction with XTP in minimum 3-packet exchange.

while there was an RFC for vmtp ... rfc1045 ... there was never a RFC for XTP ... although we did a forey at ISO (but got hung up in the rule about violating OSI model). there are a couple books written on XTP ... and I've piles of hardcopy and softcopy stuff.

my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

move down to RFCs listed by section and select TERM (term->RFC#).

in the acryonym fastpath section, select "DNSSEC". this will give you all RFCs associated with DNSSEC ... aka

domain name system security (DNSSEC )
see also domain name system , domain name system extensions , security
4322 4310 4035 4034 4033 3845 3833 3755 3658 3226 3225 3130 3110 3090 3008 3007 2931 2930 2845 2541 2540 2539 2538 2537 2536 2535 2137 2065

if you are in frames mode, selecting any RFC number will bring up the RFC summary in the lower frame. as always, selecting the ".txt=nnnn" field (in an rfc summary) retrieves the actual RFC.

GP4.3 - Growth and Fraud - Case #3 - Phishing

Refed: **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 3, 2006 01:14 PM
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000609.html

or you could go even further. the prevailing use of SSL is for hiding account numbers in payment transaction.

the long-time vulnerability for payment transactions was attacker evesdropping and/or harvesting account numbers and using them in fraudulent transactions
http://www.garlic.com/~lynn/subintegrity.html#harvest
http://www.garlic.com/~lynn/subintegrity.html#secrets
http://www.garlic.com/~lynn/subintegrity.html#fraud

effectively a form of replay-attack.

the x9a10 standards working group was given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments. the resulting protocol was x9.59.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

it had two business rules

1) transactions were strongly authenticated
2) account numbers used in x9.59 transactions would not be valid in non-authenticated transactions

this is effectively traditional countermeasures for attackers attempting replay attacks.

with the elimination of the evesdropping/harvesting vulnerability for replay attacks (fraudulent transactions) the justification for hiding the account number was drastically reduced.

x9.59 transactions had sufficient protection with simple authentication for fraud prevention and no longer needed encrypting and account number hiding to prevent fraud.

customers would register public keys with their accounts (in similar manner suggested for domain name infrastructure) ... similar to registering "mother's maiden name" or other authentication information. the consumer applies their digital signature to the x9.59 transaction and send it on its way. the transaction eventually arrives at the consumer's financial institution, validates the digital signature (with the onfile public key), does their other bit of authentication magic and authorization magic and send off the reply.

no PKI, certification authority and/or digital certificates are required. in addition, it also eliminates the requirement for SSL hiding of the account number; just simple authentication and long understood countermeausures against replay attacks.

the ancillary issue was that there were some other payment protocol activities going on concurrent with the x9.59.

we had been involved in much of the work on the original payment gateway with this little client/server startup company that had come up with SSL (and used for hiding payment transactions)
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

one of the scenarios that we looked at with respect to some of the PKI/certificate-based payments ... was just the payload size. A PKI infrastructure has the original transaction, an appended digital signature, and one or more appended digital certificates (under the assumption that the receiving party has no prior knowledge of the signer and/or their public key).

A standard ISO8583 payment transactions runs 60-80 bytes. The common appended PKI digital certificate of the period ran 4k-12k bytes. Basically, the PKI-based infrastructure planned on increasing the transaction payload size by two orders of magnitude (100 times increase in payload size) with appended PKI overhead ... solely on the justification that the receiving consumer's financial institution had no prior relationship with the consumer (which appears to be logical contridiction).

GP4.3 - Growth and Fraud - Case #3 - Phishing

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 3, 2006 03:06 PM
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#0
http://www.garlic.com/~lynn/aadsm22.htm#1

the other approach to doing the financial transaction account number vulnerability analysis is using the userid/password metaphor.

bascially an account number is used to select the account, like the functionality provided by userids. also, like userids, account numbers are required to be available and used in a large number of different business processes.

however, the account number is also used to authenticate the transaction ... i.e. knowledge of the account number is sufficient authentication in large number of payment transactions. in that use, the account number is like a password and is vulnerable to evesdropping, skimming, and/or harvesting. thus such account number uses is also like a password.

the use of an account number as both a "userid" and a "passwords" may create an horribly conflicted environment. in past periods, the industry had created countermeasures to account number guessing ... i.e. as fraud prevention in account number role as password.

however, the advent of evesdropping, skimming, and harvesting attacks sidestepped the guessing countermeasures and opened the way for replay attacks (i.e. capturuing a valid value and replaying it).

SSL and various of the PKI-based payment protocols provided countermeasure to account number evesdropping while transactions were in-flight. however, one of the long term (preceeding internet use) attacks against account numbers have been havesting account numbers from stored information. the stored transaction account information was required for a large number of business processes where the account number role is used like a "userid".

old related posting on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61
and findings that continue to show that the leading cause of data breaches associated with id/account theft involve insiders
http://www.garlic.com/~lynn/aadsm17.htm#38 ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders

this gave rise to my past comments that the planet could be buried under miles of encryption and it still wouldn't prevent account number leakages. the problem was the dual-use requirements placed on account numbers for both userid functionality and password functionality and the radically conflicted processing and protection objectives. The account number as userid functionality has to be fairly widely available. The account number as password functionality has to be kept hidden and confidential. This conflicting requirements leads to enormous problems and vulnerabilities that can't be addressed by simply hiding the account number in transit.

the solution by x9.59 retail payment standard eliminated the dual-use conflict for account numbers. account numbers were solely restricted to use as userid funtionality. digital signatures were introduced for (authentication) password functionlity. x9.59 enabled accounts would not process transactions that didn't have appropriate authentication (many of the PKI-oriented payment protocols solely addressed hiding the account number, but still allowed the account number to be skimmed or harvested and used in non-PKI and non-authenticated transactions). in this sense the old style accounts are somewhat like ftp/anonymous or "guest" accounts (except there is attempt to hide the userid) accounts and the new, x9.59 accounts require authentication independent of having the correct userid.

with the elimination of account number dual use ... it was no longer necessary to hide the account number ... since it was only be used for "userid" functionality.

static data passwords are still subject to evesdropping and replay attacks ... and therefor are required to be hidden. advantage of digital signatures for authentication (over static data passwords) is that they can be evesdropped w/o being vulnerable to replay attacks.

as previously mentioned, a separate issue with some of the PKI-based payment protocols was the enormous payload bloat (increase in payload size of one hundred times) introduced by requiring stale, static, redundant and superfluous digital certificates to be appended to payment transaction.

going back to fundamental principle of PKI, certification authorities and appended digital certificates ... is that you have digitally signed something and prepared to transmit the transaction and the appended digital signature.

The issue in PKI environment is that the targeted recipient has no prior information about you and/or has no way of doing online operation to obtain information about you. So digital certificates are created that have been certified by independent, well known parties (where the targeted recipient is believed to have some sort of trusted relationship). The targeted recipient is believed to trust the certification authority and therefor the appended digital certificate with appropriate information about you ... will be trusted (in lieu of the targeted recipient otherwise having information about you)

However, it takes quite a bit of confused thinking to believe that a consumer's financial institution has no prior knowledge about their consumers for which they have created consumer accounts and issued consumer account numbers. It is even more unbelievable that because it is believed that a consumer's financial institution has absolutely no existing relationship with the consumer (for which there is an account) ... that it justifies bloating a payment transaction payload size by a factor of one hundred times.

GP4.3 - Growth and Fraud - Case #3 - Phishing

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 4, 2006 12:28 PM
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
MailingList: Financial Cryptography
a PKI certificate-based model assumes that the relying party or recipient
  1. has no other source of information (aka the letters of credit/introduction from the sailing ship days)
  2. trust in the certifying party
a certificate-less-based model
http://www.garlic.com/~lynn/subpubkey.html#certless
assumes that the recipient and/or relying party
  1. has their own information
  2. and/or direct access to certifying party
SSH is one such certificate-less implementation.

various of the PKI payment solutions from the mid-90s were relying-party-only scenarios
http://www.garlic.com/~lynn/subpubkey.html#rpo

the relying-party-only certificate model from the mid-90s were
  1. reaction to the x.509 identity certificate standard, realizing that personal information in certificate represented serious privacy and liability issues
  2. effectively restricted the "personal" information in the certificate bound to the entity's public key was just an account number.
even at that, the certificate-based appended overhead still could represente an enormous payload bloat of 100 times.

PKI process scenario from the mid90s was that a consumer provided a public key (and proof of the private key) that the financial institution could register in the account record (akin to registering mother's maiden name).

in the traditional PKI process, this is frequently referred to as the RA or registration authority.

the financial institution then generated a (relying-party-only) digital certificate which was returned to the consumer (the certificate manufacturing part of the PKI process)

the consumer was then expected to generate a transaction, append a digital signature, and also append the digital certificate (resulting in a 100-times payload bloat).

eventually the digital signed transaction arrived at the financial institution, they pull the account number from the transaction, retrieve the account record, and then can use the public key registered in the account record to validate the digital signature.

any appended digital certificate, in addition to causing a 100-times payload bloat was truely redundant and superfluous.

the x9.59 scenario
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

can do the identical public key registration as the PKI scenario. the certificate-less process, just eliminates the manufacturing of a redundant and superfluous digital certificate and also eliminates the appending of a redundant and superfluous digital certificate on every financial transaction sent back to the consumer's financial institution (as well as avoiding the 100-times payload size bloat).

As mentioned before, neither the SSL nor the PKI-based account hiding technique actually addressed the major long-term vulnerability of account numbers (dual-use vulnerability with account number representing both the userid functionality as well as the password functionality).

old related posting on security proportional to risk (and the merchant transaction file)
http://www.garlic.com/~lynn/2001h.html#61

and that continue to show that the leading cause of data breaches associated with id/account theft involve insiders
http://www.garlic.com/~lynn/aadsm17.htm#38 ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders

similarly, the solution to major SSL domain name certificate vulnerability was the registration of a domain name user's public key. The trust root for SSL domain name certificate then changes from the identification information on file with the domain name infrastructure (and the expensive, error-prone, and time-consuming identification matching process) to the onfile, certificate-less public key (and a simpler, more reliable, and less expensive digital signature verification process).

A certificate-less, SSH-style implementation doesn't necessarily mean that there has not been any registration process and/or certification of the public key. It may just mean that there hasn't been the certificate manufacturing (a term we coined when we were doing the original payment gateway and auditing these new operations called certification authorities) process.
http://www.garlic.com/~lynn/aadsm22.htm#0
http://www.garlic.com/~lynn/subpubkey.html#sslcert

GP4.3 - Growth and Fraud - Case #3 - Phishing

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
Date: January 5, 2006 01:42 AM
MailingList: Financial Cryptography
the certificate payload bloat was so enormous for payment protocols (factor of 100 times) that X9 financial standard group (with a backing of major PKI forces) started a new work item called digital certificate compression. the idea was to come up with various compression techniques to try and get the appended digital certificate down from several thousand bytes to possibly 300 bytes.

the first thing they talked about doing was eliminating all fields that were common across all certificates by the same institution.

early on i pointed out that there was a couple of different ways of addressing the enormous payload bloat of digital certificates in payment protocols ... aside from eliminating them as being redundant and superfluous.

a perfectly valid information compression technique was to eliminate all fields that were already in possession of the relying-party (not just the fields that were common to all certificates). i quickly showed that this technique easily achieves zero-byte certificates. rather than making the rash statement of not appending stale, static digital certificates to every digitally signed transaction, i suggested that implementations should instead append zero byte certificates to every digitally signed payment transaction.

the other mechanism was to use certificate caching echnology ... if the relying party was known to have previously acquired the consumer's digital certificate and was to known to have saved it ... then it was possible to avoid appending the same digital certificate on subsequent payment transactions ... since it could be shown that the relying party was guaranteed to already have a copy.

since it was a relying party scenario, the institution being the registration authority as well as the certification authority; when the consumer registered their public key with their institution ... the institution would dutifully manufacture a full-fledge digital certificate and save it in the consumer's account record. then the institution would return a note to the consumer saying that they were saving the consumer's digital certificate on behalf of the consumer ... and therefor it was not necessary to actually send the consumer a copy of their digital certificate ... since it would just result in the consumer appending the copy to possibly thousands of future payment transactions and returning it to the financial institution. by caching the original, the financial institution was saving the consumer enormous amounts of bandwidth and processing. if the consumer wanted, they could append a short note to future digitally signed payment transactions stating that the digital certificate was already on file (in many cases, the digital certificate on file wouldn't even be a copy, but the original).

numerous past post discussing the enormous benefits of creating zero-byte digital certificates with advanced information compression technology
http://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?

long-term GPG signing key

Refed: **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: long-term GPG signing key
Date: Wed, 11 Jan 2006 13:09:38 -0700
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Ian G <iang@xxxxxxxx>, "Travis H." <solinym@xxxxxxxx>,
    cryptography@xxxxxxxx
Perry E. Metzger wrote:
Even in totally ordinary circumstances it is important to have very strong signing keys. Your comments were insupportable.

there is a somewhat separate issue having to do with security proportional to risk. minor old posting:
http://www.garlic.com/~lynn/2001h.html#61

the security acronym PAIN
P ... privacy (or sometimes CAIN and conficentiality)
A ... authentication
I ... integrity
N ... non-repudiation

part of the problem is that sometimes there is confusion between digital signatures and human signatures (implying read, understood, agrees, approves, and/or authorizes).

the technology is asymmetric keys .... involving a pair of keys, what one key encodes, the other key decodes (differentiates from symmetric key encryption where the same key is used for encryption and decryption).

there is a business process commonly referred to as public key where one key of a asymmetric key pair is identified as public and made available. the other key is identified as private, kept confidential and never divulged.

there is a business process called digital signatures where a hash of some message or document is computed and then encoded. the message/document is sent off with the appended digital signature. the recipient recomputes the hash of the message/document and decodes the digital signature with the corresponding public key. if the two hashes compare, then the recipient (or relying party) can assume:
  1. the message/document hasn't changed since transmission
  2. the message/document has been authenticated as originating from the entity associated with the public key.
the amount of risk is associated with the risk of attack on the corresponding message/document.

say the digital signature operation is used for authenticating x9.59 transactions
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

that happen to be credit card transactions where the account owner has a credit limit of $1000, all transactions are online against the account, the account public key can be deactivated when there appears to be fraud and, to the consumer the frauulent transactions, can be reversed (leaving the consumer with a maximum $50 exposure).

the existing infrastructure has no real authentication operation except for attempting to maintain the account number as a shared-secret (which implies that the account number ... rather than any public key ... has to be deactivated & replaced when there has been compromise):
http://www.garlic.com/~lynn/subintegrity.html#secret some postings on account number skimming/havesting
http://www.garlic.com/~lynn/subintegrity.html#harvest some postings on fraud & vulnerabilities
http://www.garlic.com/~lynn/subintegrity.html#fraud

compared to some of the other payment card operations that specified public key authentication ... x9.59 allowed for

1) digital signature authenticated transactions 2) account number used in authenticated transactions could not be skimmed and used in non-authenticated transactions (which some of the other specifications allowed) ... basically countermeasure to form of replay attacks and countermeasure for having to treat account number as shared-secret.

the basic issue in both (digital signature) signing keys and encryption keys is what is the risk from a compromise and based on that risk you can determine the level security required.

another consideration is the overall infrastructures. for many of the online e-commerce operations ... an ECC 163-bit signing key probably has a lot higher security strength than the rest of the infrastructure used to protect the signing key and/or the environment where the digital signature is applied. from an attackers standpoint that means that it is probably cheaper/easier to attack the infrastructure to capture the signing key ... than to try a brute-force attack on the signing key (and all of these other attacks are applicable regardless of the strength of the signing key). there may also be attacks on other parts of the infrastructure ... getting the financial institution to register a new public key (belonging to the attacker) or getting a certification authority to issue a new certificate with the attacker's public key in the name of the victim. some of these other operations may be currently weak because the claim is that they aren't currently the weakest link in overall infrastructure.

there may be other trade-offs. it is possible to get reasonably priced 14443 contactless tokens that can do ecc 163-bit digital signing in subsecond time that may be desirable in various POS or transit turnstyle operations. going to larger key sizes may exceed both the power requirement and the elapsed time requirement (in contact token operatin you can someimes trade-off peak power draw against onger elapsed time). The case can be made in some scenarios ... that the longest possible keylength be chosen if the power and elapsed time requirements aren't a major factor. However, there can be environments where power and elapsed time requirements may justify choosing a shorter keylength (within the context of the overall environment)

one of the things that payment card infrastructures have the ability to do is a real time risk evaluation on a per transaction basis and pass judgement on a wide variety of factors which might include ... key length, whether there is a certifified token protecting the signing key and what is the evaluated integrity of that token, what kind of terminal and merchant is used for the digital signing environment, the physical location of the signing, past consumer transaction history, past terminal transaction history, etc. one might imagine financial institution having different minimum token and key length requirements for different kinds of accounts and/or different kinds of transactions (based on factors like overall risk and the relative security strength in which such tokens and signing keys operate).

you might some authorities setting the requirements don't understand the overall risk and infrastructure issues ... they can always go for the maximum available for everything ... even if some of the specified requirements don't make any sense in a particular overall infrastructurt. the other may be that the infrastructure has no means of differentiating and authorizing at different levels of risk ... so that the requirements have to mandate the maximum strength for all components, always assuming the worst case risk.

there may be a lot higher risk with a (digital signature) signing public key gets confused with human signatures ... which then may carry with it the implicattion of a human read, understood, agrees, approves, and/or autherirzes the contents of what is signed, the risk exposure might also be greater is if the overall infrastructure is an offline environment that is totally dependent on digital certificates and PKI operation as opposed to a real-time, online environment that can take into account a lot larger numgber of factors (including aggregation of past transactions).


long-term GPG signing key

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: long-term GPG signing key
Date: Sat, 14 Jan 2006 12:30:25 -0700
To: Guus Sliepen <guus@xxxxxxxx>, cryptography@xxxxxxxx
Guus Sliepen wrote:
By default, GPG creates a signing key and an encryption key. The signing key is used both for signing other keys (including self-signing your own keys), and for signing documents (like emails). However, it is possible to "split" the signing key into a master key that you only use to sign other keys, and a key dedicated to signing documents. You can revoke the latter key and create a new one whenever you want, the master key is still valid. Also, when people sign your key, they sign your master key, not the subkeys. The signatures you accumulated will also still be valid. You can also keep the master key safely tucked away on an old laptop that you keep in a safe, and only export the subkeys to your workstation. That way the master key is very safe.

as in previous post ... i assert that fundamental digital signature verification is an authentication operation
http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing keys

and doesn't (by itself) carry with it characteristics of human signature, read, understood, agrees, approves, and/or authorizes.

the PKI & CA hiearchical infrastructures does tend to add those attributes to digital signature operations ... creating an equiivalence between certification digital signatures (and the private keys that produce such digital signatures) and the validity of the information being certified.

if you are starting to create a class of private keys that start to carry the attribute of whether something is true or not (i.e. the information being certified) ... then there can start to become some confusion between the difference between the private key as an authentication mechanism and the use of the private key as whether something is true or not.

I would assert that authentication private keys can be treated like a much better password technology ... not having various of the shared-secret vulnerabilities and other shortcomings.
http://www.garlic.com/~lynn/subintegrity.html#secrets

it is when you start equating private keys with certification and truth characteristics that you move into a completely different risk and threat domain.

the other foray into embellishing private keys and digital signatures with human signature type characteristics was the non-repudiation activity. however, it is now commoningly accepted that to embellish digital signatures with non-repudiation attributes requires a whole lot of additional business processes ... not the simple operation of generating an authentication digital signature.

the whole scenario of digital signing of public keys ... is not a matter of the entity performing the digital signing doing an authentication operation ... but that the entity is certifying the truth of some value ... typically related to the public key. that is a whole business process infrastructure that has to be layered on top of digital signatures (in much the same way to actually achieve non-repudiation a whole business process infrastructure has to be created that is built above any authentication digital signature).

the other characteristics is that stale, static certification ... paper or digitally signed electronic bits ... are characteristic of the offline age ... where an entity could present the certificate representing the truth of some information; as opposed to the relying party having their own access to the truth of the same information. in the transition to an online world, it is becoming less & less coming that relying parties won't have access to the truth of some piece of information (making certificates and credentials less and less meaningful). the corollary is that digitally signed certificates and private keys embellished with certification and truth characteristics become less and less meaningful.

any embellishing of digital signatures with human signature attributes (i.e. read, understood, agrees, approves, and/or authorizes) in addition to straight forward authentication, can also lead down the dual-use vulnerability path
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)

long-term GPG signing key

Refed: **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: long-term GPG signing key
Date: Sat, 14 Jan 2006 15:17:05 -0700
To: Guus Sliepen <guus@xxxxxxxx>, cryptography@xxxxxxxx
Guus Sliepen wrote:
It depends on how it is used. For example, when I sent this email, I typed in the passphrase of my PGP key, authorising GnuPG to create a signature for this email. This comes very close to "human signing". I read, understood, approve etc. with the contents of this email.

If assymetric cryptography is used to automatically sign a credit card transaction without the user having to do more than click a button, then I agree that in that situation, the digital signature is not the same as a human signature.

but as in some of the PKI forays into non-repudiation and human signatures ... there was no way for a relying party to determine the difference ... and in the previous thread of digital signature dual-use vulnerability, this can open up fraud.

at one point, some were assuming if there was a digital certificate with the non-repudiation flag set, then the digital signature indicated human signature (read, understood, agrees, approves, and/or authorizes). however, nothing in various PKI protocols provided for proving which digital certificate was actually appended to a particular digital signature (appending a non-repudiation digital certificate might imply the creation of some obligation associated with a digital signature used as a human signature; however there was no protocol provisions for establishing which form of digital signature was actually intended and/or which digital certificate was actually appended to any particular operation).

the dual-use vulnerability may have an environment where servers nominally transmit random data for signing (one of the possible countermeasures for replay attack) and the person generates a digital signature on the random data w/o having looked at the data (assuming purely authentication operation). the other party has actually substituted some sort of valid text in place of the random data and then asserts that the person has performed the digital signature implying a human signature (read, understood, agrees, approves, and/or authorizes) as opposed to implying pure authentication operation.

the crook may attempt to further substantiate the fraudulent claim by producing a digital certificate (for the corresponding public key) with the non-repudiation bit set (and PKI protocols lack provisions for differentiating which, of possible several, digital certificates might actually have been attached).

the possible dual-use for digital signatures then may lead to enormous ambiguity since the basic technology only provides for authentication ... and w/o significant additional business processes it is difficult to differentiate digital signatures used for purely authentication purposes and the grossly embellished purposes associated with human signatures.

any embellishing of digital signatures for human signature purposes, in turn, creates significant additional risk than straight-forward authentication.

a basic issue isn't what you intended when you caused a digital signature to be created ... but what can any relying-party reasonably expect that you intended ... and what can the relying-party reasonably rely on.

then, if there is any possible ambiguity as to what you may have intended when a digital signature was created, can an attacker use the existence of such ambiguity to perpetrate fraud (aka dual-use vulnerability).

Kama Sutra Spoofs Digital Certificates

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Kama Sutra Spoofs Digital Certificates
Date: Tue, 24 Jan 2006 21:53:09 -0700
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
Kama Sutra Spoofs Digital Certificates
http://www.informationweek.com/windows/showArticle.jhtml?articleID=177103418

The Kama Sutra worm can fool Windows into accepting a malicious ActiveX control by spoofing a digital signature, a security company said Tuesday.

.. snip ..

A glimpse of SIGINT 20 years ago

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A glimpse of SIGINT 20 years ago...
Date: Thu, 26 Jan 2006 13:56:40 -0700
To: cryptography@xxxxxxxx
CC: Perry E. Metzger <perry@xxxxxxxx>
Perry E. Metzger wrote:
This is a couple of weeks old, but it appears that, by accident, a lot of information on the targets and methods being used for US/Australian/NZ SIGINT about 20 years ago has come to light as the result of the release of a late New Zealand Prime Minister's papers.

http://www.stuff.co.nz/stuff/print/0,1478,3540743a6005,00.html

Among other things:

The report lists the Tangimoana station's targets in 1985-86 as "French South Pacific civil, naval and military; French Antarctic civil; Vietnamese diplomatic; North Korean diplomatic; Egyptian diplomatic; Soviet merchant and scientific research shipping; Soviet Antarctic civil. Soviet fisheries; Argentine naval; Non-Soviet Antarctic civil; East German diplomatic; Japanese diplomatic; Philippine diplomatic; South African Armed Forces; Laotian diplomatic (and) UN diplomatic."

The station intercepted 165,174 messages from these targets, "an increase of approximately 37,000 on the 84/85 figure. Reporting on the Soviet target increased by 20% on the previous year".

recent posting and glimpse of public key crypto 20 years ago
http://www.garlic.com/~lynn/2006.html#30

thoughts on one time pads

Refed: **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Fri, 27 Jan 2006 14:11:27 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>, Dave Howe <DaveHowe@xxxxxxxx>
John Denker wrote:
One drawback with this is that you have to destroy a whole disk at a time. That's a problem, because if you have a whole disk full of daily keys, you want to destroy each day's key as soon as you are through using it. There are ways around this, such as reading the disk into volatile RAM and then grinding the disk ... then you just have to make sure the RAM is neither more volatile nor less volatile than you wanted it to be. That is, you use the disk for *distribution* but not necessarily for intermediate-term storage.

is there any more reason to destroy a daily key after it as been used than before it has been used?

one of the attacks on the stored-value gift cards has been to skim the cards in the racks (before they've been activated) ... and check back later to see which cards are gone.

i was standing at grocery store checkout last week ... apparently it was the store manager ... one of the other employees came up with a gift card that somebody had bought before xmas and gave as a present. they had come back complaining that there was no money credit/left in the account. it could have simply been an computer foul-up ... and then again, it could have been somebody had skimmed the card, waited and then drained the account.

thoughts on one time pads

Refed: **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Sat, 28 Jan 2006 15:29:22 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>, Dave Howe <DaveHowe@xxxxxxxx>
John Denker wrote:
That indicates a gross lack of tamper-evident packaging, as discussed above. The store should never have activated a card that came from a package that had been tampered with.

if you have seen many of the gift cards in racks at grocery stores ... they can be skimmed w/o any tampering needed (many with no packaging at all). it might be better that they were shipped in some sort of packaging that would require tampering in order to skim.

i think that the conventional wisdom was that the cards were (nearly) worthless until activated (and so why would anybody bother with a worthless card).

thoughts on one time pads

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Sat, 28 Jan 2006 15:50:16 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>, Dave Howe <DaveHowe@xxxxxxxx>
John Denker wrote:
-- The best way to _protect_ a key after it has been used is to destroy it.

-- For keys that have yet been used, a sufficient scheme (not the only scheme) for many purposes is to package the keys in a way that is tamper-resistant and verrry tamper-evident.

ref:
http://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads

periodically there was some discussion about institutional-centric tokens vis-a-vis person-centric tokens ... in one case specifically with respect to being able to replace magstripe payment cards with tokens.

in the person-centric token scenario, the person can choose to have a single token that they could use for all authentication purposes, including all accounts (or choose how many tokens they want and which purposes each token is used for).

at one point, there were counter arguments that a single card per account (the current mechanism) was much preferred because of the lost/stolen card problem. the problem is that the prevailing threat model for lost/stolen cards is the purse or wallet containing all cards (as opposed to individual cards).

the person-centric model at least would allow a person to replace all cards (subject to common threat model) with a single token.

a major issue with cdrom one-time pads would be somebody skimming the whole cdrom.

destroying keys as they are being used would appear to only be a countermeasure to theft of the cdrom (in which case it is apparent that unused pads are compromised and should be eliminated). however, skimming the cdrom might not leave any trace that unused pads have been compromised ... which turned out to be the issue in the gift card skimming compromise.

Face and fingerprints swiped in Dutch biometric passport crack (another card skim vulnerability)

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Face and fingerprints swiped in Dutch biometric passport crack (another card skim vulnerability)
Date: Mon, 30 Jan 2006 08:53:29 -0700
To: cryptography@xxxxxxxx
Face and fingerprints swiped in Dutch biometric passport crack
http://www.theregister.co.uk/2006/01/30/dutch_biometric_passport_crack/
The crack is attributed to Delft smartcard security specialist Riscure, which explains that an attack can be executed from around 10 metres and the security broken, revealing date of birth, facial image and fingerprint, in around two hours.

.. snip ..

some recent skimming posts
http://www.garlic.com/~lynn/aadsm20.htm#1 Keeping an eye on ATM fraud
http://www.garlic.com/~lynn/aadsm20.htm#18 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
http://www.garlic.com/~lynn/aadsm20.htm#23 Online ID Thieves Exploit Lax ATM Security
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#15 [Clips] Contactless payments and the security challenges
http://www.garlic.com/~lynn/aadsm21.htm#18 'Virtual Card' Offers Online Security Blanket
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads

thoughts on one time pads

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Tue, 31 Jan 2006 09:46:02 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>
John Denker wrote:
It is worth your time to read _Between Silk and Cyanide_. That contains an example of somebody who thought really hard about what his threat was, and came up with a system to deal with the threat ... a system that ran counter to the previous conventional wisdom. It involved protecting keys before use and destroying them after use.

ref:
http://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#13 Face and fingerprints swiped in Dutch biometric passport crack (another skimming vulnerability)

if you have a scores or hundreds of one-time pads (or any other static secrets) on a cd .... and the vulnerability is skimming ... then if the already used pads are destroyed as countermeasure to skimming ... the unused pads that are also on the same cd are also vulnerable to the same skimming. say the cd was skimmed before any pads were used ... then there hasn't yet been any destroyed pads. supposedly if you provide protection sufficient for the unused pads ... then that should be protection for the used pads also (although there always is the school of thot that more security is always better).

destroying just the one time pads on a cd is countermeasure to theft ... since the theft of the cd hopefully prevents the unused pads from being used (at least by you), there potentially is vulnerability that the thief might be able to use the unused pads in some sort of attack.

the issue is that having both used and unused pads on the same CD creates a potential common vulnerability of everything on the same CD (which are in different states). once all pads have been used ... then the whole CD represents a common vulnerability state ... and the whole CD can be destroyed.

thoughts on one time pads

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Tue, 31 Jan 2006 10:20:41 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>
John Denker wrote:
I forgot to mention in my previous message:

It is worth your time to read _Between Silk and Cyanide_. That contains an example of somebody who thought really hard about what his threat was, and came up with a system to deal with the threat ... a system that ran counter to the previous conventional wisdom. It involved protecting keys before use and destroying them after use.

an open question is whether preventing anybody from accessing the cd for skimming is also sufficient for preventing anybody from accessing the cd for theft. this has some analogy to tamper-evident vis-a-vis tamper-proof.

obviously theft leaves more tell tail trails (aka tamper-evident). then, does the countermeasures for skimming (tamper-proof) have to be more stringent than countermeausures for theft (tamper-evident). destroying used pad is countermeasure for all kinds of access of the used pad. however destroying used pads still leaves vulnerability of skimming the unused pads (on the same cd). if the countermeasures for skimming the unused pads (tamper-proof) is sufficiently high ... then that may also be adequate for all kinds of access to the used pads on the same cd.

but as mentioned ... there are also the people of the school of thot that more security is always better.

serious threat models

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: serious threat models
Date: Sat, 04 Feb 2006 11:42:06 -0700
To: cryptography@xxxxxxxx
CC: Perry E. Metzger <perry@xxxxxxxx>,
    Jaap-Henk Hoepman <jhh@xxxxxxxx>
Perry E. Metzger wrote:
All phone switches, thanks to the US government's CALEA rules, are equipped with software that makes espionage easy. Whether that software was abused in this instance, I do not know, but I will point out that any switch sold in the US -- which is to say most switches that exist -- has software available (but not necessarily installed) to tap people's phones in a manner not entirely unlike what happened to the high government officials in Greece.

Yet again, I point out John Gilmore's warning that once you make law enforcement "convenient" by creating privacy invading technologies, you have very little control over who ultimately comes to use those technologies. It will not only be the good guys who get access to them, and even the guys who have legitimate access will not always be good guys.

the off-site terminal program for accessing systems online, reading email, etc, while on the road ... early 80s ... a vulnerability analysis was done and one of the biggest identified threats was hotel PBXs (frequently the room was unlocked and anybody could walk in). as a result there was work done on custom encrypting (2400) modem. basically did session key exchange on connection, so that all transmission was encrypted.

i was amazed in the 90s with the growing use of laptops and online access (traveling road warriors) and the number of people that seemed oblivious to the security issues. insecure practices that was forboten from at least 1980 (although i had online access at home for ten years prior to the encrypting modems, starting march 1970)

Major Browsers and CAS announce balkanisation of Internet Security

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Major Browsers and CAS announce balkanisation of Internet Security
Date: February 22, 2006 12:41 PM
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000662.html

this is the scenario where authentication has been allowed to get really sloppy and the solution is strong identification ... the individual scenario is having your complete lineage stapled to your forehead.

in general, identification scenarios involve being able to blame the correct entity after something bad happens (which may act as a deterrent) ... where-as, authentication scenarios typically are aimed at prevention.

the problem is that authentication requires that the entity being authenticated has some context for the entity doing the authentication; if that context doesn't exist ... then you fall back to some sort of detailed identification and hope that there is some information that provides basis for meaningful context.

during the x9.59 standards activity in the 90s, there was some investigation into carrying trademarks in certificates ... the certification authorities would only include trademarks for the entity that has registered the trademark with the appropriate gov. agency. hopefully the trademarks provide some meaningful context for the end-user ... and there are existing legal recourse for mis-use of trademarks.

an issue here then becomes similar to my oft repeated scenario for SSL domain name certificates ... the certification authorities still have this time-consuming, error-prone and expensive identification process of making sure that the entity applying for the certificate is the same as the entity registered with the appropriate authoritative agency (responsible for whatever the certificaition authorities are certifying for the certificate).

then somebody has the brilliant idea that when there is some registration with some authoritative agency ... that the registration entity also register their public key. then the certification authorities require that certificate applications be digitally signed. then the certification authorities can do a real-time retrieval of the registered public key from the authoritative agency and change an expensive, error-prone and time-consuming identification operation (i.e. the entity applying for the certificate is the same as the entity registered for the information being certificate) into a more reliable, less expensive, and simple authentication process.

the issue then is that if certification authorities can do real-time retrieval of public keys from authoritative agencies responsible for the information being certified ... why can't the general public also do real-time retrieval of the same public keys ... and be able to perform their own authentication ... rather than requiring certification authorities to do such authentication on their behalf and creating these things called digital certificates that are a representation of claims about (certification authorities) having performed some set of (authentication and/or identification) business processes.

an issue has been that public keys haven't been in general use ... so that authoritative agencies that are actually responsible for the information have no reason to require the registration of public keys from entities (as part of their general process). however, if public keys were to become generally used ... as in everybody applying for a digital certificate (from a certification authority), then there is an increasing expectation that entities will have public keys (for instance, one is required for a digital certificate). given sufficient expectation of public keys ... then the real authoritative agencies responsible for registered information can ressonably start to expect that they could also register public keys along with the rest of the information. then everybody being able to directly access these authoritative agencies actually responsible for registered inforation ... could perform their own real-time retrieval of public keys and their own authentication process (w/o requiring certification authorities as intermediaries).

A recent posting on the privacy side of this process (which is supposedly side-stepped when you are talking about identification of corporations and institutions ... as opposed to the individual)
http://www.garlic.com/~lynn/2006c.html#31 Worried about your online privacy

past postings about the effort to have public keys registered along with the registration with other information with various authoritative agencies
http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#24 Broken SSL domain name trust model
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2001l.html#22 Web of Trust
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003d.html#29 SSL questions
http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
http://www.garlic.com/~lynn/2004b.html#41 SSL certificates
http://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005i.html#3 General PKI Question
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#9 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh

"doing the CA statement shuffle" and other dances

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 5, 2006 08:41 PM
Subject: "doing the CA statement shuffle" and other dances
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000672.html
when we were doing the original payment gateway as part of the commerce server doing payment transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

looked at some number of additional things that a certificate could represent, in addition to straight-forward ssl domain name certification.

recent post about ssl domain name certificate process being compromised because original design had the user typing in the url and then the server supplied certificate matched the typed in URL implied that the server the user thot they were talking to was the server they were talking to (implicit was belief that the end-user had understanding between some entity and their URL)
http://www.garlic.com/~lynn/2006d.html#28

as the environment evolved to users simply clicking on buttons or other things (potentially supplied by an attacker) ... the ssl domain name certificate process just came to mean that any attacker was whoever their URL claimed them to be

our proposals about including more detailed checks on e-commerce merchants (possibly including things like fbi background checks on all employees) didn't catch on (also mentioned in the above post).

part of the issue was financial justification for doing the additional checking. a merchant/acquiring financial institution already does a fairly detailed check on any credit card accepting merchant (since part of a merchant/acquiring financial institution sponsoring/certifying a merchant for accepting credit card transactions ... includes taking financial liability for the merchant).

there was an issue with whether an end-user could trust an unknown merchant. the e-commerce activity was highly skewed with the majority of transactions occuring with a few well known and well branded websites, frequently repeat business. A small percentage of total e-commerce activity was spread across the vast number of websites ... each website only performing a few transactions each. The high volume merchants didn't need anymore trust ... since they had the brand and repeat business. The low volume merchants couldn't justify paying more for trusted certification ... other than what they were already paying to their merchant/acquiring financial institution as part of credit card acceptance certification.

this was still in the days when it was assumed that the user was typing in the URL and was familiar with the entity and their respective URL

the evoluation came with the disconnect with what the users perceived to be entities and clicking on arbitrary strings that provided the URL to the browsers. This created a disconnect between what the user perceived to be the entity and the URL supplied to the browser. Attackers could provide things to click on that claimed to be some well-known entity, but actually generated some totally unrelated URL. Then the attacker only had to provide a certificate that proved that they were who the URL claimed they were (as opposed to any textual claims as to who they were).

So there possibly are a couple different countermeasures to this vulnerability/exploit. One is to create some variety of trusted "clicks" (which have evolved as a substitute for actually typing in the URL). As part of creating trusted "clicks", there is some user involvement in establishing the relationship between who the user thinks the entity represented actually is, the "trusted" click, and the resulting URL (which was implicit in the original SSL model that assumed the user would be typing in the URL value and understood the relationship between some entity and their URL).

An alternative is some sort of high assurance certificate and some browser visual indication when the browser is dealing with a high assurance certificate (as opposed to any run of the mill certificate).

The high assurance certificates don't eliminate the disconnect for end-users where some text can claim that clicking will invoke one thing ... but actually invokes something else different (the only thing that ssl domain name certificates does is prove that you are who your URL claims you to be ... as opposed to what any text surrounding a click may claim you to be).

Implicit is an assumption that attackers won't be able to obtain a high assurance certificates (and all the entities that can obtain high assurance certificates won't involve themselves in impersonations).

to some extent the certificate-based model is that the end-user needs to have no local support infrastructure ... that it can all be supplied by institutional entities.

the "trusted" click model assumes that the end-user has some sort of local support infrastructure ... for recording and preserving their "trusted" clicks. "trusted" click model could even allow clicking on externally supplied clicks ... and having the browser tell you whether it mapped to a trusted click entry and who was the entity associated with the entry (even visual clues similar to that proposed for high assurance certificates).

note this is effectively similar/same as earlier post on "trusted" bookmarks:
http://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model

"doing the CA statement shuffle" and other dances

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 6, 2006 03:46 PM
Subject: "doing the CA statement shuffle" and other dances
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000672.html
http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances

from the end-user standpoint, the "trusted click" paradigm, using something analogous to bookmarks, can be quite similar to cellphone phone books (using caller-id to maps to different ring tones) or email address books (where spam blockers may rate incoming different if the origin address is in the address book).

that doesn't address spoofing the origin email address or spoofing the caller-id ... but in the web paradigm, basic ssl is used to catch that type of spoofing.

the current issue is the disconnect with the click paradigm ... where users are presented with to something to click ... and attempts are made to obfuscate the URL domain name (SSL provides the connection between the URL domain name and the website ... but the click paradigm allows for a disconnect between the end-user and the actual URL domain name coming off the click).

digital certificate cps, gov. legislation, and audits can be viewed as attempts to get around the TTP/CA business model being alien to standard business operations. In standard business operations, the relying party has business relationship with the certifying agency and typically there is some exchange of value (implicity or explicity contract). In the typical TTP/CA business model there is no business relationship and/or obligation between the CA and the relying parties. CPS, gov. legislation and audits are approaches that attempt to provide a sense of comfort for relying parties in certifications performed by CAs (where it doesn't otherwise exist in normal business practice).

GSA addressed this in the Federal PKI by signing contracts with all approved certifying agencies issuing digital certificates .... essentially making them agents of GSA (for issuing digital certificates). Then then federal gov., as relying party, could rely on the issued digital certificates because of their (gsa) contract with the certification authorities.

note in previous comments, theoritical use of digital certificates is by relying parties where they have no information about the subject entity and/or no (other) way of obtaining such information. in the digital certificate analogy to letters of credit/introduction, the relying party (when there was no other means of obtaining information) could record information from the letters of credit/introduction in their local repository. typically a letter of credit/introduction wouldn't be repeatedly presented on every interaction, but recorded locally. the local record is then used for future interactions.

so a local trusted repository (bookmarks, public key repository, address book, phone book, etc) is used to record information about interactions. when no other information is readily available (either locally or via direct contacts with reputable agencies ... in the domain name case, it could be direct contract with the domain name infrastructure and retrieving registered public key at the same time registered ip-address is retrieved), then individual's local repository might be populated on first-time interaction between two total strangers with information supplied by digital certificate.

Paradigm that repeatedly presents such credentials on every interaction typically assume that the relying party has no ability to maintain local repository (or past information).

The scenario of acquiring/merchant financial institutions implicitly certifying merchants that can perform credit card transactions, involves contracts between consumer and their consumer/issuing financial institution, the consumer/issuing financial institution and the associations, the associations and the acquiring/merchant financial institution, as well as the acquiring/merchant financial institution and the merchant. this series of contracts creates obligations between the consumer and the merchant. furthermore, the acquiring/merchant financial institution stands behind the merchant (taking financial liability), and in return takes a percentage of every financial transaction.

In the title insurance scenario ... the relying party (consumer) pays the title insurance company for the certification (direct business contract between the relying party and the certification agency).

As mentioned, in the typical TTP/CA business operation there is no direct contractual relationship between the relying party and the certification agency.

slight drift, part of thread on caller id "spoofing"
http://www.garlic.com/~lynn/2006d.html#31 caller id "spoofing"

which is the analogy between the URL and the webserver and is directly addressed by ssl domain name certificates ... which is different than the vulnerability created with the browser "click" disconnect. lots of past posts about ssl domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

for even more drift, a recent posting about frequent semantic confusion the result of having the word "signature" occur in both the terms "human signature" and "digital signature"
http://www.garlic.com/~lynn/2006d.html#34 When *not* to sign an e-mail message?

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 8, 2006 10:53 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000673.html

it has actually gone thru a number of generations ... and somewhat is starting to look a little more like x9.59
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

see the discussion here (slight access problem, so had to resort to the wayback machine)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

with earlier version having gotten the label yes card in the UK press (see last paragraph in above).

early x9.59 and chip&pin work were going on about the same time. x9.59 looked at straight-forword authentication of the transactions ... while chip&pin has somewhat gone thru a number of iterations starting to converge on the idea of actually authenticating the transaction (as opposed to various mechanism possibly authenticating separately from doing the transaction).

misc. past posts mentioning yes card:
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004j.html#44 Methods of payment
http://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 10, 2006 02:33 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?

events this week may be bringing more attention to transition away from implementations with skimming, harvesting, and/or MITM vulnerabilities. small roundup of this week's new articles


Citigroup blocks cards in three nations after breach
http://www.marketwatch.com/News/Story/Story.aspx?guid=%7B4CAA5EFD%2DE932%2D4D14%2D8279%2D03D2446352C9%7D&siteid=mktw&dist=moreover
International Citibank Customers Shaken By Data Breach
http://www.banktech.com/aml/showArticle.jhtml?articleID=181502448
International Citibank Customers Shaken By Data Breach
http://www.securitypipeline.com/news/181502240
Citibank Data Breach | International Citibank Customers Shaken By Data Breach
http://www.informationweek.com/showArticle.jhtml?articleID=181502068
Citi Blocks Some Debit Cards After Breach
http://www.smartmoney.com/bn/on/index.cfm?story=ON-20060308-000922-1159&nav=pf_hp
Citibank cards pulled after network breach
http://www.networkworld.com/news/2006/030706-citibank-network-breach.html
Citibank blocks ATM cards after retailer breach
http://www.finextra.com/fullstory.asp?id=15014
Citibank Data Breach
http://www.compliancepipeline.com/news/181502758
Citibank probes ATM withdrawals, cites potential U.S. 'retailer breaches'
http://www.computerworld.com/securitytopics/security/story/0,10801,109308,00.html
As Banks Reissue Debit Cards, Experts Warn of More Compromises
http://www.digitaltransactions.net/newsstory.cfm?newsid=877
Debit card fraud spree linked to security breach
http://software.silicon.com/security/0,39024655,39157043,00.htm
Citibank Confirms Fraud in Canada, UK, Russia Linked to Breach
http://www.eweek.com/article2/0,1895,1934988,00.asp
Debit Card Fraud Tied to OfficeMax Breach
http://www.eweek.com/article2/0,1895,1935677,00.asp
Debit card fraud outbreak raises questions about data breach
http://www.computerworld.com/industrytopics/retail/story/0,10801,109427,00.html
IBNLive : PAN card fraud busted in Mumbai
http://www.ibnlive.com/article.php?id=6584&section_id=7
E-Fraud | PIN Scandal 'Worst Hack Ever'; Citibank Only The Start
http://www.informationweek.com/news/showArticle.jhtml?articleID=181502474
US banks fall victim to large-scale hacking and skimming fraud
http://www.finextra.com/fullstory.asp?id=15030
Citibank uncovers debit card fraud
http://www.orlandosentinel.com/business/chi-0603090170mar09,0,3699639.story?coll=orl-business-headlines
Citibank uncovers debit card fraud
http://www.sun-sentinel.com/business/local/chi-0603090170mar09,0,4638004.story?coll=sfla-business-headlines
Citibank uncovers debit card fraud
http://www.chicagotribune.com/technology/local/chi-0603090170mar09,1,1026651.story?coll=chi-technologylocal-hed
PINs no obstacle for debit card thieves
http://msnbc.msn.com/id/11731365/
PINs no obstacle for debit card thieves
http://www.msnbc.msn.com/id/11731365/
Huge ATM Scam May Be Global in Scope
http://www.14wfie.com/Global/story.asp?S=4610973&nav=3w6o
Citibank card fraud - magnetic strip to blame?
http://www.silicon.com/financialservices/0,3800010322,39157105,00.htm
Debit Card Fraud Jumps
http://www.accountingweb.com/cgi-bin/item.cgi?id=101885
Officials: ATM PINs Stolen On Massive Scale
http://www.thewbalchannel.com/consumeralert/7860927/detail.html
Citibank responds to ATM fraud concerns
http://www.atmmarketplace.com/news_story_25260.htm
Card Skimming Is ATM Industry's Biggest Fraud
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1141822818622215212&block=
New debit card fraud tied to West Coast case http://news.com.com/New+debit+card+fraud+tied+to+West+Coast+case/2100-1029_3-6047100.html?tag=nefd.top
New debit card fraud tied to West Coast case
http://news.zdnet.com/2100-9595_22-6047100.html
New debit card fraud tied to West Coast case
http://news.com.com/2100-1029_3-6047100.html?part=rss&tag=6047100&subj=news
New debit card fraud tied to West Coast case
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=19548
Fraudsters target Citibank - Breaking
http://www.smh.com.au/news/breaking/fraudsters-target-citibank/2006/03/07/1141493649374.html
Citibank issues ATM fraud statement
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=19529
Citibank issues ATM fraud statement
http://www.securityfocus.com/brief/157
Citibank reissues cards after fraudulent withdrawals
http://www.channelregister.co.uk/2006/03/07/citibank/
Citibank Reissues Some Payment Cards After Fraudulent Withdrawals
http://www2.csoonline.com/blog_view.html?CID=18837
Security Bytes: Scope of debit card fraud may be widening
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1172241,00.html
PIN Scandal 'Worst Hack Ever;' Citibank Only The Start
http://www.techweb.com/wire/security/181502468
Idiot Watch Citibank Locks Down ATM Cards
http://www.securitypronews.com/news/securitynews/spn-45-20060306IdiotWatchCitibankLocksDownATMCards.html
Citibank Blocks Some Debit-Card Use Abroad
http://www.firstcoastnews.com/money/news-article.aspx?storyid=53363

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 12, 2006 12:35 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000673.html

some more from yesterday ... including some discussion on characteristics of static data and replay attacks
http://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"

part of the issue w/x9.59 ... that originally started going on in the same time-frame as the original chip&pin ... was that the x9a10 financial standards working group was given the requirement (for x9.59) to preserve the integrity of the financial infrastructure for all retail payments (ALL as in ALL ... not just point-of-sale, not just internet, or not just a specific type).
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

some drift about internet-specific activities (but not POS) in the mid-90s
http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question

and previous post on work for POS-specific (but not internet) starting in the same time-frame
http://www.garlic.com/~lynn/aadsm22.htm#20

a few from today:
Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit Fraud
http://www.digitaltransactions.net/newsstory.cfm?newsid=738
That key-chain credit-card fob is an identity theft risk
http://www.mailtribune.com/archive/2006/0312/biz/stories/02biz.htm
Debit cards offer less security than credit cards (less protection under reg-E)
http://www.newsobserver.com/104/story/416556.html
PIN Scandal "Worst Hack Ever;" Citibank Only The Start
http://news.com.com/News.com+Extra/2001-9373_3-0.html?tag=rsspr.6048737
National ATM Card Breach Affecting Triangle Cardholders
http://www.wral.com/news/7859809/detail.html
Banks Issue New Debit Cards After Security Breach
http://www.nbc17.com/money/7859819/detail.html
Breach Of Security Among Debit Card Companies
http://abclocal.go.com/kgo/story?section=7on_your_side&id=3982441
Thieves Compromise Debit Card PINs
http://www.nbc5i.com/news/7857280/detail.html
New Theft Scam Targets Debit Cards
http://www.wsfa.com/Global/story.asp?S=4615928&nav=0RdE
Credit Card Scams
http://www.khqa.com/news/news_story.aspx?id=3875
Thousands Becoming Victims of ATM Fraud
http://www.ksl.com/?nid=148&sid=173996&comments=true
Debit card hackers in huge ATM theft
http://news.monstersandcritics.com/northamerica/article_1135877.php/Debit_card_hackers_in_huge_ATM_theft
Citibank blocks some debit cards
http://www.kansascity.com/mld/kansascity/business/personal_finance/14059928.htm
Debit-card security addressed
http://www.timesleader.com/mld/timesleader/14073650.htm
Hackers crack PINs, rob foreign banks
http://www.bangkokpost.com/breaking_news/breakingnews.php?id=84143
If You Can't Trust Your Bank, Who Can You Trust?
http://www.informationweek.com/blog/main/archives/2006/03/if_you_cant_tru.html
Something In The Cards Prompts Citigroup To Call Them Quits
http://www.institutionalinvestor.com/default.asp?page=1&SID=618305&ISS=21459&type=8

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 12, 2006 03:49 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
part of the issue was a lot of the early chip&pin work was oriented towards card vulnerabilities.

skimming (starting by at least the early 90s) and the yes card are attacks against the infrastructure and the POS terminals.

there may be the possibility of MITM-attacks against dynamic data authentication of the chip ... i.e. separate from the chip performing transaction ... something that was looked at in X9.59 work (in the same time frame as the original chip&pin work) and required authentication of the transactions ... as opposed to authentication separate from the transaction. part of this is understanding broader landscape of threat models ... misc. on MITM-attacks ... but also some discussion of threat modeling
http://www.garlic.com/~lynn/subintegrity.html#mitm

however a possible vulnerability (in POS terminal attack) is that since both static data and dynamic data are part of the authentication specification ... even if all new cards deployed are "dynamic" ... terminals may still continue to have support for static data specification. in such a scenario, it might be possible for a skimming attack to still acquire sufficient (static data) information to turn around and build an acceptable counterfeit yes card (where it then convinces a terminal that it is a valid, older static data chip).

earlier yes card reference
http://www.garlic.com/~lynn/aadsm22.htm#20

and the more detailed discussion of yes card
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

part of the above is the mention about it staying around forever (or at least as long as any POS terminals continue to have chip&pin static data specification support).

NPR : E-Mail Encryption Rare in Everyday Use

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use
Date: Tue, 14 Mar 2006 09:20:46 -0700
To: cryptography@xxxxxxxx
Victor Duchovni wrote:
Of course new domains are less than $4 each in bulk... How will you lock out throw-away domains? The black-list problem for email is not solved. The good lists are nowhere near 100% effective. Is the equivalent of port 25 blocking tractable for Jabber? Is there a difference between the user-to-server port/protocol and the server-to-server port/protocol in Jabber?

we were on a business trip and staying in Scottsdale ... not very long after the green card incident. one night we walked over to a Mexican restaurant in old town. during the dinner, three people came in and were seated behind us, a couple and a man that was sat directly behind me.

the man spent the evening explaining to the couple how he could spam the world on behalf of their e-commerce webserver ... and also how they should configure their webserver (no demons other than webserver, especially no sendmail since some number of the millions of people he would spam might complain by attempting to send email to their webserver host name).

he explained that his spamming process was to use some userid to send out enormous amount of commercial spams (usenet &/or email). At some point, the ISP would eventually get sufficient complaints and shutdown his userid. however, he had scores of userids (at different ISPs all over the country) already pre-setup (this was back in the days when it was still common to get shell accounts) with spamming software already preloaded and configured. He could immediately switch to some other userid with no interruption to his spamming activity ... and periodically he would establish new userids and preload them with his spamming software.

minor green card historical reference:
http://en.wikipedia.org/wiki/Green_Card_spam

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 16, 2006 10:29 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)

Confusion reigns over identity of merchants who sparked fraud
http://www.computerweekly.com/Articles/2006/03/15/214826/Confusionreignsoveridentityofmerchantswhosparkedfraud.htm
related old standby post, security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61
and more recent thread
http://www.garlic.com/~lynn/2006e.html#26
Up To 600,000 PIN-Debit Cards Affected In Hack
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1142513626622215212&block=
Your secret PIN may not be so secret
http://news.com.com/Your+secret+PIN+may+not+be+so+secret/2100-1029_3-6050259.html?tag=nefd.lede
Say Hi to the mouse click capturing Trojan (some number of companies have been promoting mouse clicks as countermeasure to pin-capture keyloggers)
http://www.theregister.com/2006/03/16/mouse_click_capturing_trojan/
NACHA Starts Drive to Sign up Participants for Web-Payment Pilot
http://www.digitaltransactions.net/newsstory.cfm?newsid=882
Nacha to pilot online authentication concept
http://www.finextra.com/fullstory.asp?id=15056

after having done aads pilot in 2000
http://www.garlic.com/~lynn/x959.html#aads
http://www.garlic.com/~lynn/x959.html#aads

Poor authentication increases risk of identity fraud
http://www.whatpc.co.uk/vnunet/news/2152120/poor-authentication-increase
Hackers cash in on financial sector attacks
http://www.infomaticsonline.co.uk/vnunet/news/2152006/financial-sector-top-target
Ignoring data breaches means ignoring risk management
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1173214,00.html >

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 17, 2006 01:42 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
and if you haven't gotten tired of the current rash of fraud related news .... here is a few more. also a related post from sci.crypt
http://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now

....

Huge Hack Threatens to Cool off Torrid Growth of PIN Debit Payments
http://www.digitaltransactions.net/newsstory.cfm?newsid=883
Identity Theft Expert Says the Theft of Customers' PIN Numbers from a Major Bank Shows High-Tech Fraud Knows No Bounds
http://www.expertclick.com/NewsReleaseWire/default.cfm?Action=ReleaseDetail&ID=12021
Skimming scares off cash machine users
http://www.silicon.com/financialservices/0,3800010322,39157323,00.htm
Banks do battle with debit-card fraud
http://news.zdnet.com/2100-1009_22-6050777.html
Banks take on debit-card theft
http://news.com.com/2009-1029_3-6050794.html?part=rss&tag=6050794&subj=news
Banks do battle with debit-card fraud
http://news.com.com/2100-1029_3-6050777.html?part=rss&tag=6050777&subj=news
Banks told to adopt stronger authentication
http://www.silicon.com/financialservices/0,3800010322,39157367,00.htm
Your secret PIN may not be so secret
http://news.com.com/Your+secret+PIN+may+not+be+so+secret/2100-1029_3-6050259.html?tag=nefd.top
US payment association to test bank-verified online payments
http://www.cbronline.com/article_news.asp?guid=EC14F55D-7CA3-4CD2-BCA0-CCCE4CD73E6D
House Slated to Pass Data Breach Bill
http://www.securitypronews.com/insiderreports/insider/spn-49-20060316HouseSlatedtoPassDataBreachBill.html
The intersection of Sarbanes-Oxley and insider threats
http://www.computerworld.com/networkingtopics/networking/story/0,10801,109527,00.html
Phishing scammers and data thieves prey on UK companies
http://www.zone-h.org/en/news/read/id=205999/

Meccano Trojans coming to a desktop near you

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 25, 2006 11:38 AM
Subject: Meccano Trojans coming to a desktop near you
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000680.html

The nodes (data at rest) have always been the most at risk. part of this is that data-at-rest tends to have much larger collection of aggregated data tending to result in much higher return for the crooks effort. Furthermore ... long before the internet and continuing right thru the internet period ... the majority of fraud has always involved insiders ... again primarily an end-node related issue ... not data-in-transit issue.

at best, most PKI efforts for data-in-transit, was to not result in any incremental risk with the introduction of the internet ... as opposed to really addressing any of the primary threats and vulnerabilities. however, internet not also provided some incremental threat against data-in-transit ... but the internet also allowed for some additional threats/attacks against end-nodes. however, the various possible internet threats against end-nodes ... may represent as much an obfuscation of identifying the actual compromise (insiders), as any real threat, in itself.

However, some number of the end-node infrastructures originally evolved in a disconnected, non-threat environment ... and as a result did not have inherent designed-in countermeasures for operating in a high threat/advisary (internet) environment.

somewhat related discussion
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense

Meccano Trojans coming to a desktop near you

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 26, 2006 09:54 AM
Subject: Meccano Trojans coming to a desktop near you
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000680.html
http://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to a desktop near you

There was a online banking conference circa 1995 where the banks talked about moving to the internet. pre-internet, a bank supporting online banking ... a typical bank had their own "bank" of (dial-in) modems and claimed to require 50-60 different versions of software for different kinds of PCs with different software versions and modem hardware (along with a well-staffed online banking trouble call center).

the move to internet banking ... eliminated almost all of their trouble calls, all their own software development and support operation and the big call center ... effectively moving that to an ISP. The ISP amortized the call-in connection across all the stuff that user might do online and the internet-paradigm standardized the end-user connectivity software with a paradigm that used the same software across all online operations. this represented something like 95percent plus reduction in costs to a financial institution for supporting online operations.

there were some bank factions that had vested interests in preserving the roll-your-own, dedicated operational paradigm, but the internet-based operation cost savings were enormous (which was at least partially because of standardizing and amortizing online operational costs across everything that an end-user did online)

A big issue with many of the consumer end-nodes has been many of the underlying platforms originally evolved in a non-hostile environment with no built-in defensives. Furthermore a large body of applications (like games) evolved where it was common to take-over (and compromise) the whole system as part of normal operation.

As a result, some of these platforms now have quite diametricly opposing requirements ... attempting to apply a defensive layer as an after thot (i've frequently used the analogy of auto aftermarket seatbelts as a safety measure from the 60s) to deal with potentially extremely hostile internet operation while still preserving the ability for various applications to compromise the system (as part of normal operation). The 60s aftermarket seatbelts was before the complete make-over to having some amount of fundamental built-in product safety.

Meccano Trojans coming to a desktop near you

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 26, 2006 07:09 PM
Subject: Meccano Trojans coming to a desktop near you
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#28 Meccano Trojans coming to a desktop near you

part of this going back to at least the early 90s is that crooks would physically install compromises on end nodes (atm machines, pos/point-of-sale terminals) to skim/collect information on possibly tens of thousands of accounts.

this internet scenario involves installing a trojan on a end-node ... possibly getting only a couple accounts per node ... however, the trojan can be done electronically ... w/o having to physically visit each node. basically the same skim/harvest static information vulnerabilities has just been extended to a much larger number of end-node collection points.

previously mentioned was that skimming threat came into existance at least in the early 70s with the introduction of magstripe cards and electronic transactions.

however, one of the earliest magstripe vulnerabilities is somebody using the algorithm that checks for correctly formed account number ... to generate an account number and create a counterfeit magstripe with that account number. an early countermeasure for this threat was cvv genre ... basically a hash of the magstripe that is encrypted with the bank's secret key. the first part of each account number has the bank BIN ... which is used for indexing a table for electronically routing the transaction. The same network table can have the bank secret key ... so that the CVV value from magtripe can be validated (an early version of digital signature ... but using secret key instead of private/public key).

While the cvv process was a countermeasure to algorithmic generated account numbers and counterfeit magstripes ... it was subject to skimming vulnerabilities ... i.e. just copy/skim a valid magstripe and reproduce the magstripe information on a counterfeit card ... basically a form of replay attack.

the yes card compromise mentioned recently
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)

was basically a variation on cvv scenario. the magstripe information was incorporated into a digital certificate ... with the certification authority's digital signature. the chip would present the digital certificate as evidence of being a valid chip. the pos terminal would validate the (certification authority's) digital signature on the digital certificate. proving a valid digital signature on a digital certificate was equivalent to proving a valid chip.

Basically, this generation of chip cards could be skimmed using the same technology that skimmed magstripes. Validating the digital signature on the digital certificate was equivalent to validating the cvv on the magstripe ... in both cases, that validation was treated as being equivalent proving a valid card (the process for the digital signature was more complex than any cvv ... but any difficulty making an electronic copy was essentially identical)

The yes card label came because the POS terminals were programed that once the terminal validated the digital certificate, they would accept the chip's statements/directions. The (counterfeit) yes cards would say: YES, the entered pin is correct; YES, the transaction is within the credit