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§ion_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/
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 limit; YES, do an offline transaction (don't trouble the backend, online system with the transaction, aka criminal's countermeasure to the account being turned off, which is effective with compromised magstripe cards).

This was subsequently enhanced so that newer cards would negotiate "dynamic" authentication (instead of simple "static" authentication). the POS terminal could send a random challenge ... which the chip digitally signs with its private key. So now the terminal verifies the certification authority's digital signature on the digital certificate ... and then uses the public key in the digital certificate to validate the digital signature on the random data.

this use of dynamic data (digital signature on random data) is countermeasure to skimming static data ... and effectively various forms of replay attacks.

One of the scenarios looked at by the x9a10 working group (given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... as part of x9.59 financial standards work in the mid-90s
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
was whether there might be a mitm-attack against scenario where authentication is performed separately from the actual transaction.

One possible scenario has a valid lost/stolen card paired with an electronic mitm ... the initial authentication is transparently passed to the lost/stolen card ... and then all subsequent communication is handled by the mitm ... as per the yes card scenario. A far-out scenario has the lost/stolen card connecting to some internet communcation unit (built by the bad guys). several mitm have wireless internet communication and the challenge/digital signature exchange is actually communicated over the internet.

given a possible mitm-attack and the yes card scenario ... it isn't even necessary for a criminal organization to obtain a large number of lost/stolen cards.

misc. past posts mentioning various mitm-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitmattack

the similarity here is that static data authentication continues to be still be in wide-spread use enabling replay attacks and skimming/harvesting/phishing operations against a wide variety of end-nodes.
http://www.garlic.com/~lynn/subintegrity.html#harvest

Creativity and security

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Creativity and security
Date: Mon, 27 Mar 2006 09:15:30 -0700
To: Joseph Ashwood <ashwood@xxxxxxxx>
CC: cryptography@xxxxxxxx
Joseph Ashwood wrote:
The one I find scarier is the US restaurant method of handling cards. For those of you unfamiliar with it, I hand my card to the waiter/waitress, the card disappears behind a wall for a couple of minutes, and my receipt comes back for to sign along with my card. Just to see if anyone would notice I actually did this experiment with a (trusted) friend that works at a small upscale restaurant. I ate, she took my card in the back, without hiding anything or saying what she was doing she took out her cellphone, snapped a picture, then processes everything as usual. The transaction did not take noticably longer than usual, the picture was very clear, in short, if I hadn't known she was doing this back there I would never have known. Even at a high end restaurant where there are more employees than clients no one paid enough attention in the back to notice this. If it wasn't a trusted friend doing this I would've been very worried.
Joe


the trivial case from nearly 10 years ago was the waiter in nyc restaurant (something sticks in my mind it was the Brazilian restaurant just off times sq) that had pda and small magstripe reader pined to the inside of their jacket. At some opportunity, they would causally pass the card down the inside of their lapel (doesn't even really have to disappear anyplace). This was before wireless and 802.11 ... so the magstripe images would accumulate in the pda until the waiter took a break ... and then they would be uploaded to a PC and then to the internet (hong kong was used as example) ... counterfeit cards would be on the street (opposite side of the world), still, within a few hours at most.

recent post mentioning some skimming threats
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to desktop near you

Creativity and security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Creativity and security
Date: Mon, 27 Mar 2006 09:53:47 -0700
To: Joseph Ashwood <ashwood@xxxxxxxx>
CC: cryptography@xxxxxxxx
ref:
http://www.garlic.com/~lynn/aadsm22.htm#30 Creativity and security

and a more recent skimming news item from this month:

Cloned-card scams socking it to bank accounts
http://www.mysanantonio.com/news/metro/stories/MYSA030506.09B.atm_theft.27d5322.html

the above card mentions pins with debit cards ... which is typically required for atm machines for withdrawing cash ... but the new class of debit cards with logos can also be used w/o pins at pos terminals (aka at pos, it is option selection to decide whether the debit card is used with or w/o pin).

various recent postings mentioning skimming attacks:
http://www.garlic.com/~lynn/2006e.html#2 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
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
http://www.garlic.com/~lynn/aadsm22.htm#13 Face and fingerprints swiped in Dutch biometric passport crack (another card skim vulnerability)
http://www.garlic.com/~lynn/aadsm22.htm#14 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#15 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you

Meccano Trojans coming to a desktop near you

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

discovery by financial industry needing to design-in security from the start
http://www.securitypipeline.com/183702555

i was made aware of the necessity of doing designed-in from the start as an undergraduate in the late 60s ... nearly 40 years ago.

it wasn't until several years later that i was made aware that a lot of stuff i was doing as an undergraduate was being used in places like this
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

lots of archived posts ... many from alt.folklore.computers about early days of cp67 in the 60s
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

and various other posts about the science center from the 60s and 70s
http://www.garlic.com/~lynn/subtopic.html#545tech

Meccano Trojans coming to a desktop near you

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@garlic.com>
Date: April 1, 2006 11:10 AM
Subject: Meccano Trojans coming to a desktop near you
MailingList: Financial Cryptography
anon writes
I can assure you that the technology is real. However, unlike newcomers like Verisign/iDefense, those who actually work on mitigation share their findings only with banks and law enforcement, and not the general public. As a result, the attackers don't know why things don't work for them as expected, which has tactical advantages.

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
http://www.garlic.com/~lynn/aadsm22.htm#28 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#32 Meccano Trojans coming to a desktop near you

there are actually two sides. one is the technologists and defenders not divulging information to the attackers. the other has been that the technologists and the attackers not divulging information to the public.

the previously referenced yes card
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin

had the attackers thoroughly understanding chip&pin skimming attacks (since possibly late 90s) ... but the information didn't appear to be readily available to the technologists and defenders attempting to understand the possible threat models. one might then be tempted to attribute that the chip-card solution recreating a more modern version of static cvv (as a countermeasure to counterfeit cards built from scratch, as opposed to the long time threat of counterfeit cards built from skimmed information).

there is the scenario controlling public information to place attackers at disadvantage. there has also frequently been the case that the attackers have all the information and the lack of public information places the defenders at a disadvantage. the comment in the yes card summary was that the information had been widely available to attackers for a number of years (although apparently not to the general public or defenders designing countermeasures).

one possible way of characterizing the scenario is that the cvv and other static data solutions were countermeasures to attacks on cards. the problem was that the skimming and yes card solutions were using skimming to attack the terminals and infrastructure (using valid skimmed data for replay attack against the terminals and infrastructure).

in the requirement given in the mid-90s to the x9a10 standards working group for x9.59 standard to preserve the integrity of financial infrastructure for ALL retail payments ... was that a major recognized threat was skimming and data breaches (i.e. the yes card reference claims that the original chip&pin specification work was going on in the same period as the original x9.59 standards work).

part of the threat analysis was that account number use was grossly overloaded ... and therefor created significant vulnerabilities. The account number was required in large number of places and business processes for the operation of payments (has to be openly divulged and generally available).

At the same time, knowledge of the account number was frequently sufficient for performing a transaction ... a static data (vulnerable to skimming and data breach threats), shared-secret, something you know authentication. from 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

and shared-secret something you know
http://www.garlic.com/~lynn/subintegrity.html#secret
http://www.garlic.com/~lynn/subintegrity.html#harvest

the x9.59 standards process was to completely separate and differentiate the account number from any authentication role. the account numbers could be openly divulged and made generally available but had no authentication role (business rule that account numbers used for x9.59 transactions could not be used for transactions that didn't have separate authentication). in the x9.59 standards process much of the current security breaches and data breaches become a mute issue since the information can't be used for fraudulent transactions (effectively replay attacks).

the skimming, harvesting, and security/data breach scenarios involved replay attacks against the terminals and infrastructure (although they may possibly have involved counterfeit cards built from skimmed data). this is totally distinct from other types of efforts that are designed to be countermeasures against attacks on valid cards. the issue was that if you could trivially skim information to be used in attacking the terminals and other parts of the infrastructure (w/replay attacks ) ... it was possible to totally bypass having to attack the cards themselves.

a similar situation may be currently being played out in various legislative bodies. with lost/stolen cards and online transaction infrastructure; you typically notice that the card has been lost/stolen, report the information, and the account number can be "turned off", possibly even before any fraud has actually occurred. in the skimming, harvesting, and security/data breach scenarios the individuals won't realize it has happened (until they start noticing fraudulent charges and/or when all the money is gone).

cal. state legislature passed a bill that required individual notifications when breaches had occurred. that somewhat gave the individual a small additional advantage to report earlier than they would if they had to wait until all the money was gone. several other states then passed similar laws and/or are considering such laws. Work has also has begun at the federal level. however, there have been some stories in the press about there being significant lobbying at the federal level that the federal notification bill would pre-empt any state legislation and significantly reduce the situations where notification was actually required (one might be tempted to draw parallels with the jokes about the "CAN-SPAM" legislation; bills having exact opposite effect of what might be inferred by their title).

The excuse of controlling information available to attackers ... seems to have also resulted in some number of situations where the information has been readily available to the attackers (in some cases for many years) and it is controlled from being available to everyone else (at least some number of people developing threat models for use in designing countermeasures ... need a lot of information about existing attacks).

Note ... as mentioned, with respect to breach notification ... part of the x9.59 standards effort from the mid-90s was to eliminate large number of the breach scenarios as representing an actual security threat and vulnerability. the skimming, harvesting, and breach scenarios (for replay attacks) are further aggravated by the fact that the long term data has shown that the majority of such fraud has involved insiders (having legitimate access to the information).

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 2, 2006 11:37 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
there were possibly a couple million of these (chip&pin) cards issued in this time-frame (this article dated 14sep2000)
http://www.computerworld.com/industrytopics/retail/story/0,10801,50230,00.html

that were of the variety described in the last paragraph of this smartcard trip report
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

as mentioned elsewhere, a lot of the chip&pin countermeasures had concentrated on compromise of a valid card, as opposed to attacks on terminals or infrastructure that have been signature of skimming/harvesting/phishing ....
http://www.garlic.com/~lynn/subintegrity.html#harvest

for instance a valid card was normally configured to periodically specify doing an online, realtime transaction. if the card had been reported lost/stolen ... the account could be turned off ... which works for online, realtime transactions. however, as originally intended, the cards would typically perform most of their transactions offline. as a result there was provision to issue a "die" command to a card that had been reported lost/stolen (the next time it went online, besides having the account turned off in the backend). This die/suicide countermeasure was to eliminate a crook continuing to have an operational, valid lost/stolen card that would work for the offline transactions but would "fail" possibly every tenth transaction (the periodic online transaction that it had been programmed for).

Infrastructure replay attacks, along with stuff like mitm attacks, were considered by the x9.59 standards work starting in the mid-90s; at about the same time that the original chip&pin specification work was going on; aka the x9a10 standards working group had been given the requirement for x9.59 standard to preserve the integrity of the financial infrastructure for ALL retail payments. misc. x9.59 references:
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
misc. mitm-attack postings
http://www.garlic.com/~lynn/subintegrity.html#mitmattack

as mentioned in the ref. smartcard trip report, counterfeit yes cards ... created from skimmed data, would be programmed to never go online ... so turning off the account in the backend had no effect ... and also there would be no opportunity to issue the "die" command (even if counterfeit yes cards weren't programmed to suicide). the report does mention that some of the more simpler counterfeit card implementations might still periodically go online ... but as implied in the above report ... would not honor the command to commit suicide ... aka from the last paragraph in above ref. smartcard trip report:

Weaker clones will go online, but they still cannot be shut down. Therefore, unless they are physically removed, clones are there forever once they are made.

... in this scenario, the weaker clones, for the situations where there was eventually an online connection ... that transaction would be declined (i.e. the account had been turned off in the backend) ... but the clone would be programmed to ignore the suicide command, and therefor could still be retained and used later in other offline transactions. a crook might just have a variety of clone/counterfeit cards and substitute one that wouldn't go online (and therefor that transaction would be approved).

previous posts
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you

later cards have been updated with dynamic authentication (of the card) as a countermeasure to skimming attacks (used with the production of counterfeit cards). one issue is that since the skimming replay attacks (with counterfeit yes cards) were against the terminals (not against valid cards), all terminals need to have all provisions for static authentication (as per the original specification) eliminated. the other issue is that since the authentication (of the card) is separate from the transaction, there may be the possibility of mitm attacks. at the very least, a mitm card can filter all commands to die from ever getting to a valid lost/stolen card.

4th April, 1984

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 2, 2006 11:37 AM
Subject: 4th April, 1984
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000690.html

I consider my recent rant about digital certificates has some similarities with regard to various kinds of corruption of what something actually means.

digital certificates are a type of certificate/credential that is just one way of representing some certification of some fact or other information.

however, in some situations the meaning of certificate/credentials have been corrupted to the point that they take on a meaning all by themselves ... as opposed to just being one form of representing something. I've frequently used the phenonama of diplomas cranked out by diploma mills as one such example. The possession of a piece of parchment can take on a life of its own, totally independent of what the piece of parchment was originally intended to represent.

this may be a major contributing factor behind the existing browser SSL compromise scenarios, any valid SSL certificate and the associate closed padlock appears to have taken on meaning totally independent of the actual certified information/facts/process that the certificates supposedly represent.

recent posts
http://www.garlic.com/~lynn/2006f.html#15 trusted certificate and trusted repository
http://www.garlic.com/~lynn/2006f.html#16 trusted repository and trusted transaction
http://www.garlic.com/~lynn/2006f.html#17 trusted certificate and trusted repository

Unforgeable Blinded Credentials

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Unforgeable Blinded Credentials
Date: Wed, 05 Apr 2006 10:37:44 -0600
To: John Denker <jsd@xxxxxxxx>
CC: Hal Finney <hal@xxxxxxxx>, cryptography@xxxxxxxx,
    ben@xxxxxxxx
John Denker wrote:
The phrase "there are no sensitive secrets today" sounds very strange by itself, and doesn't sound much better in context.

I assume the intended meaning was more along the lines of: == The set of things you want to keep secret has zero overlap with == the set of things you might want to use as an identifier.


this is sort of the track of the x9a10 working group activity started in the mid-90s on the x9.59 financial standard ... which had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments.

the analysis was that the account number had become grossly overloaded. on one hand it was mainstay of normal business process required to be widely available and divulged for large number of different business processes. on the other hand, it was also effectively being used for authentication; aka knowing the account number was frequently sufficient for authenticating the transaction. misc. posts related to havesting account numbers
http://www.garlic.com/~lynn/subintegrity.html#harvest

the severely conflicting requirement for account number use ... on one hand being widely available and divulged for large number of different business processes ... and on the other hand needing to be kept private and confidential for authentications purposes ... created opportunity for numerous compromises. this also somewhat has led to my periodic observation that the planet could be buried under miles of cryptography (for hiding account numbers) and it still wouldn't be sufficient to prevent account numbers from leaking.

this is further aggravated by the long term findings that the majority of fraud have involved insiders who have legitimate access to the information. it is even further aggravated by account number being static data and therefor vulnerable (as an authentication mechanism) to evesdropping/skimming/harvesting and replay attacks.

x9.59 called for dynamic data on the actual transaction for authentication (as countermeasure to both replay attacks and mitm attacks). x9.59 also called for account numbers used in x9.59 transactions would not be honored when used in "non-authenticated" transactions (countermeasure to skimming, security breaches, and data breaches).

the combination of specifications, in the x9.59 standard, drastically reduced the sensitive nature of account numbers. the crooks could have all the skimming, security breaches and data breaches involving account number sources and it would be insufficient to execute fraudulent transaction.

a few recent posts mentioning x9.59 drastically reducing sensitive nature of account numbers.
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006f.html#16 trusted repositories and trusted transactions
http://www.garlic.com/~lynn/aadsm22.htm#1 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you

and my old long time standby of security proportional to risk ... with regard to the possible large discrepancy involving the value of skimmed account number data to the crooks (in the current infrastructure) vis-a-vis the worth of account number data to retail merchants (the crooks can possibly afford to mount a massive attack that merchants can't reasonably be expected to afford to defend against)
http://www.garlic.com/~lynn/2001h.html#61

Meccano Trojans coming to a desktop near you

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 7, 2006 03:05 PM
Subject: Meccano Trojans coming to a desktop near you
MailingList: Financial Cryptography
i started work on virtual machines nearly 40 years ago as an undergraduate in the late 60s. a lot of stuff that i did was picked up and shipped in the standard product ... which turned out to have a number of security minded customers. trivial reference to the period:
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

I also mentioned the above reference earlier in this same thread:
http://www.garlic.com/~lynn/aadsm22.htm#32 Meccano Trojans coming to a descktop near you

I've joked in recent years that as an undergraduate, I was getting requests (sometimes w/o being told the source) to implement one thing or another ... that turned out to be security related ... for some things that haven't bubbled up to the top of current lists of security concerns (in many cases, security had severely regressed ... things that we had thot were done and fixed over 30 years ago keep reappearing).

misc. other collected posts about virtual machine activity from the period
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#545tech

some of the virtual machine security benefits was because of strong partitioning ... any compromises tended to have their scope significantly limited.

another benefit was that the virtual machine kernel ... providing the strong partitioning ... was (at least at the start) small and compact ... and it was relatively straight forward to do a detailed audit. the interfaace and API semantics were also concise and the API implementation audit was also straight forward.

another thing that has come back into style is free software. it use to be pretty much all software was free ... but in large part because of various gov. litigation ... "unbundling" (another term for charging for software) was announced on june 23rd, 1969. This was primarily for application software, the gov. being told that the kernel software still had to be free since it was part of the correct operation of the hardware.

Later in the 70s, I was given the opportunity to be the guinea pig for kernel priced software. This transition was somewhat the result of the appearance of clone mainframe manufacturs. The competitors were shipping mainframe clones and telling their customers to just order the "free" kernel. Much of the resource manager software I had done as an undergraduate had been dropped in the morphing from 360s to 370s. My "new" (and ever improved) resource manager (30th anniversary of its official product announce is coming up in a couple weeks) was going to be the guinea pig for kernel priced software and I was rewarded with getting to spend a lot of time with the business planners and lawyers regarding working out policy for pricing kernel software. misc. collected posts mentioning unbundling
http://www.garlic.com/~lynn/submain.html#unbundle

the rest of the posts in this thread:
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
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#32 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you

Creativity and security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Creativity and security
Date: Sat, 08 Apr 2006 08:31:45 -0600
To: cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
the trivial case from nearly 10 years ago was the waiter in nyc restaurant (something sticks in my mind it was the Brazilian restaurant just off times sq) that had pda and small magstripe reader pined to the inside of their jacket. At some opportunity, they would causally pass the card down the inside of their lapel (doesn't even really have to disappear anyplace). This was before wireless and 801.11 ... so the magstripe images would accumulate in the pda until the waiter took a break ... and then they would be uploaded to a PC and then to the internet (hong kong was used as example) ... counterfeit cards would be on the street (opposite side of the world), still within a few hours at most.

ref:
http://www.garlic.com/~lynn/aadsm22.htm#30 Creativity and security

supposedly new?

iPod used to store data in identity theft
http://news.com.com/2061-10789_3-6059128.html

from above ..
April 7, 2006 4:55 PM PDT
A 35-year-old identity theft suspect may have taken Apple Computer's mandate, "Think Different," a little too far.

... snip ... and above article references:

Beware the 'pod slurping' employee
http://news.com.com/Beware+the+pod+slurping+employee/2100-1029_3-6039926.html?tag=nl

... from above ...
Published: February 15, 2006, 10:29 AM PST
A U.S. security expert who devised an application that can fill an iPod with business-critical data in a matter of minutes is urging companies to address the very real threat of data theft.

... snip ...

and some conjecture about a possible MITM-attack ... using counterfeit card in conjunction with PDA wireless internet connection to a lost/stolen valid card at some remote location.
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#29 Mecccano Trojans coming to a desktop near you

This is scenario where a card may be authenticated separately from its actual operation. The hypothetical MITM-attack is against a terminal's willingness to agree with the business rules in an authenticated (valid?) card used for offline transactions. Since the attack is against the offline transaction business rules in an authenticated card, it may not even be necessary to obtain a lost/stolen valid card ... it may just be just necessary to obtain any valid card (say thru valid application using false information) ... the MITM counterfeit card uses any valid card for the authentication exchange ... and then proceeds with the rest of the transaction using its own business rules.

as mentioned previously the x9a10 standards working group had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments for x9.59 standard ... and as such had to consider the full gamete of possible threats and vulnerabilities (including range of replay-attacks and MITM-attacks).
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

misc. past postings mentioning various MITM-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitmattack
lots of past postings mentioning any sort of fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 8, 2006 12:48 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
with regard to divulging threats and vulernabilitiess ... there frequently isn't a lot of public information ... although it appears that there is all kinds of information widely available to attackers.
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you

there is some discussion found here with regard to yes card operation:
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

x9a10 had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments (including, at least both point-of-sale and internet; aka a common protocol that was resistant to ALL attacks, threats and vulnerabilities in ALL environments). as a result, a broad gamate of vulnerabilities and threats had to be considered ... including various kinds of skimming and replay attacks as well as various kinds of MITM attacks ... some reference
http://www.garlic.com/~lynn/aadsm22.htm#38 Creativity and security

part of this, is that various kinds of replay attacks and MITM attacks can seem more obvious in a internet setting ... however similar type of attacks can't be ruled out for point-of-sale.

following is website describing chip&pin implementation and deployment
http://www.astara.co.uk/HighStreetRetailers/

however, from the above URL (near the bottom of the page):
Please note that for reasons of security, TransactDirect does not support EMV Chip&PIN connectivity via the Internet.

... snip ...

while not stating what the security issues are ... it strongly implies that there are attacks against chip&pin use in an internet setting. based on the earlier x9.59 financial standards work, we had found that numerous of the internet oriented vulnerabilities actually also tended to have analogous attacks in a physical world setting.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 8, 2006 04:07 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
Iang G wrote:
Lynn, how does the chip&pin stuff in the US relate to the rollout in the UK? Are they the same things? Does that mean we can assume the history repeats itself?

re:
https://www.financialcryptography.com/mt/archives/000673.html

this references chip&pin rollouts in the US in 2000/2001 time-frame involving possibly a couple million cards
http://www.computerworld.com/industrytopics/retail/story/0,10801,50230,00.html

this 2002 trip report describes yes card vulnerabilities in chip&pin rolled out up until that time (eu, uk, us, etc):
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

I recently ran across a web page that stated that there have been over 400 million chip&pin deployed world-wide since chip&pin first started in 1995(?)

I've heard that at least some of the vulnerability/threats (mentioned in the 2002 card trip report) have been addressed.

However, the comment at this page discussing current uk chip&pin roll-out
http://www.astara.co.uk/HighStreetRetailers/

mentions that there are still security issues with using chip&pin in internet environment.

in this posting
http://www.garlic.com/~lynn/aadsm22.htm#39

the x9a10 standards found that most of the internet-based threats and vulnerabilities turned out to have corresponding threats and vulnerabilities in the physical and point-of-sale world.

the x9a10 standards work started in the mid-90s, with the requirement to preserve the integrity of the financial infrastructure for ALL retail payments, had to consider a broad variety of threats and vulnerabilities (for ALL possible retail payments, including at least both internet and point-of-sale).
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

part of this work drew on our earlier efforts having worked on the original payment gateway with a small client/server startup in the valley that had this technology called SSL and was looking at doing payments from their server (commoningly referred to now as e-commerce)
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

In 1998 time-frame, based on the x9.59 standards work, we had also drafted the RFI response to the NACHA internet payments trials
http://www.garlic.com/~lynn/x959.html#aads
http://www.garlic.com/~lynn/nacharfi.htm

In the same time-frame, we had put out requirements to vendors for aads chip strawman. rather than exactly specify what the chip did, we specified the requirements that such chips had to meet:
  1. dynamic data transaction authentication (preferrably some form of digital signature)
  2. available in both contact and contactless (iso 14443) forms
  3. be able to do transaction authentication in the transit gate elapsed time requirements AND in the iso 14443 power limitations
  4. aggresive cost reduction, throw-out everything that wasn't directly required to do dynamic data transaction authentication
minor aads chip strawman reference from the period:
http://www.garlic.com/~lynn/aadsm2.htm#straw

I had made jokes in the period about taking a $500 mil-spec part, extremely aggresive cost reduction to better than two orders of magnitude, while at the same time improving on the security and integrity.

The dynamic data transaction authentication addresses both the skimming/replay attacks characteristic of static data transaction authentication as well as various MITM-attacks when the chip/card is authenticated separately from the transaction.
http://www.garlic.com/~lynn/subintegrity.html#mitmattack

Part of this was from fundamental application of 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor Part of the issue seems to be a large amount of attention payed to countermeasures for various kinds of attacks on valid cards. However, the actual threat descriptions appear to be against other parts of the infrastructure ... where various existing vulnerabilities have been exasherbated with the introduction of chip&pin ... or the introduction of chip&pin have resulted in new kinds of vulnerabilities in other parts of the infrastructure (like the yes card reference to chip&pin introduction of offline transactions negating the usefullness of deactivating accounts, which works for online transaction environment).

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

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2006 10:56 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
Lynn wrote:
minor aads chip strawman reference from the period:
http://www.garlic.com/~lynn/aadsm2.htm#straw


I had given a talk on AADS at Assurance panel in the trusted computing track at the spring 2001 Intel Developer's Conference
http://www.garlic.com/~lynn/index.html#presentation

During my talk, I quiped that it was nice to see that TPM had started to look more & more like AADS chip strawman over the previous couple years. The guy running TPM effort was in the front row and quiped back that was because I hadn't a committee of a couple hundred people helping me design AADS.

note in the previous post ... I had dropped a reference to crucial AADS requirement which was extremely aggresive cost reduction ... which I've included in the embellished archived version:
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin

Votes are coins stamped with the Red Queen's head

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2006 11:32 AM
Subject: Votes are coins stamped with the Red Queen's head
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000692.html

I remember reading some study about GNP can be severely under estimated in some economies ... since GNP tends to be very money oriented. below a certain level, production for self-use and barter is supposedly more efficient. above some threshold, organizational distribution may have some efficiencies ... as long as the economy of scale is such that it offsets the costs and overhead of the middlemen and other intermediary costs. The money construct helps improve that efficiency and helps offset the intermediary costs and overhead.

as an aside ... as an exercise in the past, I took the online CIA world factbook files and loaded the extracted information into a database, merging it with information from the online Worldbank economic files and the online UN demographic files. Trivial exercise was that they didn't use a completely consistent country naming nomenclature ... so I also loaded the ISO standards file of country names and used it to resolve the descrepancies (and normalize all the information to common country names).

A fundamental issue underlying the Boyd OODA-loop construct is the time element ... if you can cycle your OODA-loop faster than a competitor, you will have an advantage. Lots of my past posting on Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
misc. Boyd and/or OODA-loop references from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2

There is something of a secondary question with OODA-loops ... is the advantage strictly because of time ... or are you faster because of superior skill and experience, which then is also a contributing factor in having an advantage. "Getting there first" can convey a lot of tactical advantage ... but skill and experience can also contribute to "getting there first".

Many of Boyd's historical examples of the time element were drawn from military history ... recent topic drift about Boyd's example of Guderian and the blitzkrieg
http://www.garlic.com/~lynn/2006f.html#14 The Pankian Metaphor

The above also mentions Boyd's comments about massive, heavy, top-down bueracracies not being very agile and/or adaptable.

brief footnote ... the same technology that I used for merging the world fact book information, the world bank economic information and the UN demographic information ... is what I also use for managing the ietf rfc information
http://www.garlic.com/~lynn/rfcietff.htm
and the various merged taxonomies and glossaries
http://www.garlic.com/~lynn/index.html#glosnote

Votes are coins stamped with the Red Queen's head

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2006 11:58 AM
Subject: Votes are coins stamped with the Red Queen's head
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#42 Votes are coins stamped with the Red Queen's head

oh, for other drift ... indirect reference to EBRD somewhat attempting to emulate the old "Marshall Plan"
http://www.garlic.com/~lynn/2006f.html#9 The Pankian Metaphor
http://www.garlic.com/~lynn/2006f.html#10 The Pankian Metaphor

Creativity and security

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Creativity and security
Date: Wed, 12 Apr 2006 10:28:33 -0600
To: cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
recent posts mentioning some skimming threats
http://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to desktop near you


re:
http://www.garlic.com/~lynn/aadsm22.htm#30 Creativity and security

Trial starts on swipe-and-go card; A new smartcard could result in shorter queues in the shops
http://www.theage.com.au/news/business/trial-starts-on-swipeandgo-card/2006/04/12/1144521400790.html


the above has the quote:
"The card never leaves your hand," ... "In fact, it need not even be taken out of the wallet, and there is no chance information from the card can be skimmed, the most common form of card fraud."
... snip ...

while the earlier reference is to a situation where the crook is using their own device for extra swipes, a significant portion of skimming involve (regular POS terminals and ATMs) compromised devices that harvest information
http://www.garlic.com/~lynn/subintegrity.html#harvest

as part of a normal transaction. The real issue is whether "static data" is used for authentication and therefor the infrastructure is vulnerable to any kind of skimming/harvesting/evesdropping and replay attacks.

a few recent comments about static data exploits for replay attacks
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006f.html#39 X.509 and ssh

Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 14, 2006 11:54 AM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000697.html

the issue is does the existance of a digital signature demonstrate human intent ... i.e. that the person has read, understood, aggrees, approves, and/or authorizes the content.

the issue raised when we were helping word smith the california state and federal electronic signature laws involved being able to demonstrate human intent.

infrastructures have used automatically applied digital signatures for demonstration of authentication and that the subject matter has not been modified. the automatic application of digital signature negates it being used as demonstration of human intent.

it is possible to create an infrastructure where digital signatures are used for authentication and integrity ... aka out of the security PAIN acronym

P ... privacy (sometimes CAIN, confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

(NOTE there are also signaficant issues with any application of non-repudiation which has frequently also been severely misunderstood concept)

... in any case, an infrastructure can include digital signatures (for authentication and integrity) along with something totally different for the demonstration of intent.

A simple example is existing POS debit card terminals. The swiping of the card and the entry of the PIN are used for two-factor authentication ... from three factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor Neither the card swipe nor the PIN entry are taken as demonstration of human intent ... and therefor a human signature. The POS terminal separately asks for you to hit the "yes" (or agree, confirm, etc) button as indication of human intent (and therefor the equivalent of human signature, aka you have read, understood, aggree, approve and/or authorize).

In the mid-90s, the x9a10 financial standards working group was given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments for the x9.59 financial standard.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

So translating X9.59 to the debit card POS, take a chip card that digital signs a transaction at POS terminal. This demonstrates (single factor) something you have authentication and also provides "integrity" (as per definition of digital signature). Hitting the "yes" button is still required to establish human intent (i.e. the display shows "hit 'yes' to approve", aka read, understood, aggree, approve, and/or authorize)

The chip can be (card) contact or contactless (or any other form factor) ... as per aads chip strawman (from 1998)
http://www.garlic.com/~lynn/aadsm2.htm#straw

A chip can be configured and certified to indicate whether a correct PIN has been entered as part of the signing. This would add a second authentication factor (something you know). Some of the current PIN operations are shared-secrets ... in that the replying party has a copy of the secret to validate "you know what you know". Chips can be configured for purely non-shared-secrets ... where only the chip (you own) knows the secret ... but relying parties accept the certified operation of the chip as including correct PIN entry.
http://www.garlic.com/~lynn/subintegrity.html#secrets

As mentioned in some number of previous references ... the nominal purpose of multi-factor authentication is to have authentication mechanisms with different vulnerabilities. Nominal, a PIN (something you know) is countermeasure to lost/stolen card, and the card (somethin you have) is countermeasure to evesdropping the PIN.

For a little drift, there has been some issues over at least the past 10-15 years with the use of static data as indication of authentication for both something you know and something you have. Compromised or counterfeit devices (pos terminal, atm machines, etc) are modified to record static data as part of normal operation. The skimming (as part of normal operation of doing the transaction at such a device) represents a common vulnerbility; all static data (magstripe, PIN, etc) can be recorded at the same time (negating the point of multi-factor authentication assumptions about independent threats, exploit, attack).

The issue for x9.59 is that digital signatures represent dynamic data ... changing on every use. This is a countermeasure to (evesdropping/skimming) replay attacks involving evesdropping/skimming of purely static data authentication (whether performed by extra swipes on a separate device purely designed for harvesting information, or a standard device that has been compromised)
http://www.garlic.com/~lynn/subintegrity.html#harvest

The unique private key (especially in a hardware token) is (unique) something you have authentication and the (dynamic) digital signature is countermeasure to any evesdropping/skimming (including countermeasure to evesdropping any something you know PIN). The PIN can still be used for two-factor authentication as a countermeasure to lost/stolen token.

The direct application of the x9.59 digital signature to the actual transaction is (also) countermeasure to (man in the middle) MITM-attacks.
http://www.garlic.com/~lynn/subintegrity.html#mitm

recently discussed
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin

For even further drift, there have been some recent news articles about contactless cards may be immune to skimming attacks because the transaction can be done w/o it ever leaving your person. This can be viewed as a countermeasure of extra swipes capturing static data for replay attacks
http://www.garlic.com/~lynn/aadsm22.htm#30 Creativity and security

but is not a countermeasure to POS devices used for standard transactions having been compromised or counterfeited (for skimming static data as part of replay attacks)
http://www.garlic.com/~lynn/aadsm22.htm#44 Creativity and security

another item similar to the one mentioned in the above:
http://www.morerfid.com/details.php?subdetail=Report&action=details&report_id=1578&display=RFID

the issue now, isn't whether it leaves your possession but whether the authentication data is "static" (as in the case of magstripes) or "dynamic" (changing on every use, as can be the case with the use of digital signatures). Dynamic data is general countermeasure to skimming of static data for use in replay attacks.

Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 14, 2006 02:36 PM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
addenda
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures. and signs deatch warrant for Digital Signatures

... sort of to futher complete the threat landscape.

Compromised and/or counterfeit devices (POS terminals, atm machines) have been used for skimming (authentication) static data for the purposes of replay attacks.

The countermeasure is to have a least one authentication factor be "dynamic" (as a countermeasure to replay attacks).

There is possible threat with compromised/counterfeit devices against "dynamic data" implementations ... that is where the device performs multiple (valid) transactions with an authentication token (w/o the owner's knowledge) or performs the actual transaction for a different value than shown the user.

In the skimming scenario, the crooks want to leave the compromised/counterfeit device in place as long as possible, so that it potentially can provide information for replay attacks against tens of thousands of accounts; aka the actually attacks are done as far away from the compromised/counterfeit device to minimize its character being revealed (leave it in place to maximise its information gathering).

"dynamic data" authentication (like digital signatures) provide preventive to fraudulent replay attack transactions. turning off the account also can provide countermeasure to fraudulent replay attack transactions ... but frequently only after some fraud has occured.

A compromised/counterfeit device doing multiple (or incorrect value) transactions with a "dynamic data" hardware token (w/o the owner's knowledge) tends to quickly reveal itself ... which means that it is more likely to be discovered and eliminated (compared to the scenario with skimming compromised/counterfeit devices) ... and therefor much less fraud is likely (and the threat is much lower).

However, one of the x9.59 scenarios for countermeasure to multiple (or incorrect value) transaction fraud was a device and process totally under the owner's control ... like a wireless PDA or cellphone. This is one of the scenarios from the 1998 aads chip strawman
http://www.garlic.com/~lynn/aadsm2.htm#straw

where the possible form factors include PDA or cellphone device that is totally under the owner's control (as countermeasure to compromised/counterfeit device performing multiple or incorrect transactions). this, of course, is modulo virus/trojans compromising the PDA/cellphone and performing fraudulent transactions.

Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 14, 2006 04:21 PM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
in the work on electronic signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

... it wasn't that digital signatures were useless ... digital signatures could provide both authentication and integrity. However for the demonstration of human signature ... something additional was required (proof of some process or other action, in addition to just the simple existance of a digital signature).

this is compareable to some of the more recent work supposedly in the area of non-repudiation (the term still has huge amount of confusion) where there are specific processes, which in some cases, are attempting to provide demonstration of intent.

the existance of the digital signature doesn't demonstrate intent (just provides authentication and possibly integrity), it is the existance of some set of other things that are used for demonstration of intent.

note, with regard to digital signature providing authentication and integrity ... mentioned in the earlier posts
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures. and signs deatch warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures. and signs deatch warrant for Digital Signatures

one of the issues mentioned with regard to attempts fixing the yes card vulnerabilities and other similar implementations, which make use of digital signature on some challenge/response (random) data for authenticating the token (as countermeasure to replay attacks) ... since the actual transaction isn't being signed ... it isn't providing any integrity for the actual transactions (as repeatedly pointed out as a characteristic of x9.59 financial standard); it purely is a token authentication play, providing nothing additional for integrity (just authentication). It also potentially leaves a big opening for mitm-attacks.
http://www.garlic.com/~lynn/subintegrity.html#mitm

misc. recent posts mentiong the yes card scenarios
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)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)

Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

Refed: **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 14, 2006 05:14 PM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
for a little more completeness on the digital signature threat landscape ... there is also a vulernability if digital signatures on challenge/response (random) data (as countermeasure to replay attacks) are intermixed with digital signatures on valid data ... where there is possible misunderstanding that such digital signature implies human intent aka read, understood and aggrees, approves, and/or authorizes (possibly because of semantic confusion with the two terms: "digital signature" and "human signature" both containing the word signature).

this is where an attacker substitutes valid transaction for some random data in a challenge/response protocol.

past threads discussing the dual-use vulnerability in possible scenarios where digital signature is misconstrued as actually carrying any human intent properties
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)
http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#28 solving the wrong problem
http://www.garlic.com/~lynn/aadsm20.htm#37 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#10 Clearing sensitive in-memory data in perl
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#6 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#7 long-term GPG signing key
http://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?

AADS Postings and Posting Index, next, previous - home