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
https://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
https://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
https://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
https://www.garlic.com/~lynn/subintegrity.html#harvest
https://www.garlic.com/~lynn/subintegrity.html#secrets
https://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.
https://www.garlic.com/~lynn/x959.html#x959
https://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)
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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:
https://www.garlic.com/~lynn/aadsm22.htm#0
https://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
https://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
https://www.garlic.com/~lynn/aadsm17.htm#38
ID theft usually an inside job
https://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
- has no other source of information (aka the letters of
credit/introduction from the sailing ship days)
- trust in the certifying party
a certificate-less-based model
https://www.garlic.com/~lynn/subpubkey.html#certless
assumes that the recipient and/or relying party
- has their own information
- 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
https://www.garlic.com/~lynn/subpubkey.html#rpo
the relying-party-only certificate model from the mid-90s were
- reaction to the x.509 identity certificate standard, realizing that
personal information in certificate represented serious privacy and
liability issues
- 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
https://www.garlic.com/~lynn/x959.html#x959
https://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)
https://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
https://www.garlic.com/~lynn/aadsm17.htm#38 ID theft usually an inside job
https://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.
https://www.garlic.com/~lynn/aadsm22.htm#0
https://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
https://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
https://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://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))
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
https://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
https://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
https://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
https://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
https://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:
https://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:
- the message/document hasn't changed since transmission
- 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
https://www.garlic.com/~lynn/x959.html#x959
https://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):
https://www.garlic.com/~lynn/subintegrity.html#secret
some postings on account number skimming/havesting
https://www.garlic.com/~lynn/subintegrity.html#harvest
some postings on fraud & vulnerabilities
https://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
https://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.
https://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
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
https://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.itjungle.com/big/big110706-story01-fig01.html
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
https://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:
https://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
https://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)
Refed: **, - **, - **
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
https://www.garlic.com/~lynn/aadsm20.htm#1 Keeping an eye on ATM fraud
https://www.garlic.com/~lynn/aadsm20.htm#18 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
https://www.garlic.com/~lynn/aadsm20.htm#23 Online ID Thieves Exploit Lax ATM Security
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#15 [Clips] Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm21.htm#18 'Virtual Card' Offers Online Security Blanket
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing key
https://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads
https://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:
https://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://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)
https://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
https://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
https://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
https://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#24 Broken SSL domain name trust model
https://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
https://www.garlic.com/~lynn/2001l.html#22 Web of Trust
https://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
https://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
https://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
https://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
https://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
https://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
https://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
https://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003d.html#29 SSL questions
https://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
https://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
https://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
https://www.garlic.com/~lynn/2004b.html#41 SSL certificates
https://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
https://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
https://www.garlic.com/~lynn/2005e.html#22 PKI: the end
https://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
https://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005i.html#3 General PKI Question
https://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
https://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
https://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
https://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product
https://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#9 PGP Lame question
https://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
https://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
https://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
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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)
https://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:
https://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
https://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"
https://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
https://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"
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
see the discussion here (slight access problem, so had to resort to
the wayback machine)
https://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:
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
https://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
https://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
https://www.garlic.com/~lynn/2004j.html#39 Methods of payment
https://www.garlic.com/~lynn/2004j.html#44 Methods of payment
https://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
https://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:
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
https://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/software/business-intelligence/sas-makes-triple-play/240153951
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/092106-rfid-passports.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.tgdaily.com/content/view/34284/118/
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
https://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).
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
some drift about internet-specific activities (but not POS) in the mid-90s
https://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
https://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/08/windows_vista_t.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
https://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
https://www.garlic.com/~lynn/aadsm22.htm#20
and the more detailed discussion of yes card
https://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:
https://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:
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
https://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
https://www.garlic.com/~lynn/2001h.html#61
and more recent thread
https://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
https://www.garlic.com/~lynn/x959.html#aads
https://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
https://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
https://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
https://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:
https://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to a desktop near you
https://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
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://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.
https://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
https://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:
https://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:
https://www.garlic.com/~lynn/2006e.html#2 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing key
https://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm22.htm#13 Face and fingerprints swiped in Dutch biometric passport crack (another card skim vulnerability)
https://www.garlic.com/~lynn/aadsm22.htm#14 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm22.htm#15 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
https://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:
https://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
https://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
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
and various other posts about the science center from the 60s and 70s
https://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
https://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#28 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://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
https://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
https://www.garlic.com/~lynn/subintegrity.html#3factor
and shared-secret something you know
https://www.garlic.com/~lynn/subintegrity.html#secret
https://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
https://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 ....
https://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:
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
misc. mitm-attack postings
https://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
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://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
https://www.garlic.com/~lynn/2006f.html#15 trusted certificate and trusted repository
https://www.garlic.com/~lynn/2006f.html#16 trusted repository and trusted transaction
https://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
https://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.
https://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
https://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006f.html#16 trusted repositories and trusted transactions
https://www.garlic.com/~lynn/aadsm22.htm#1 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://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)
https://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:
https://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:
https://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
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://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
https://www.garlic.com/~lynn/submain.html#unbundle
the rest of the posts in this thread:
https://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#28 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#32 Meccano Trojans coming to a desktop near you
https://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:
https://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.
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
https://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).
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
misc. past postings mentioning various MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitmattack
lots of past postings mentioning any sort of fraud
https://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.
https://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:
https://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
https://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.
https://www.garlic.com/~lynn/x959.html#x959
https://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):
https://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
https://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).
https://www.garlic.com/~lynn/x959.html#x959
https://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)
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://www.garlic.com/~lynn/x959.html#aads
https://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:
- dynamic data transaction authentication (preferrably some form of
digital signature)
- available in both contact and contactless (iso 14443) forms
- be able to do transaction authentication in the transit gate
elapsed time requirements AND in the iso 14443 power limitations
- 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:
https://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.
https://www.garlic.com/~lynn/subintegrity.html#mitmattack
Part of this was from fundamental application of 3-factor
authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
- something you have
- something you know
- something you are
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:
https://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
https://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:
https://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
https://www.garlic.com/~lynn/subboyd.html#boyd
misc. Boyd and/or OODA-loop references from around the web
https://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
https://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
https://www.garlic.com/~lynn/rfcietff.htm
and the various merged taxonomies and glossaries
https://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:
https://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"
https://www.garlic.com/~lynn/2006f.html#9 The Pankian Metaphor
https://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
https://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to desktop near you
re:
https://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
https://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
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
https://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
https://www.garlic.com/~lynn/subintegrity.html#3factor
- something you have (the card)
- something you know (the PIN)
- something you are (typically some form of biometrics)
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.
https://www.garlic.com/~lynn/x959.html#x959
https://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)
https://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.
https://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)
https://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.
https://www.garlic.com/~lynn/subintegrity.html#mitm
recently discussed
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin
https://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
https://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)
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures. and signs deatch warrant for Digital Signatures
https://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.
https://www.garlic.com/~lynn/subintegrity.html#mitm
misc. recent posts mentiong the yes card scenarios
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://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
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
https://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
https://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#28 solving the wrong problem
https://www.garlic.com/~lynn/aadsm20.htm#37 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#10 Clearing sensitive in-memory data in perl
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#6 long-term GPG signing key
https://www.garlic.com/~lynn/aadsm22.htm#7 long-term GPG signing key
https://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
AADS Postings and Posting Index,
next, previous
- home