Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- GP4.3 - Growth and Fraud - Case #3 - Phishing
- GP4.3 - Growth and Fraud - Case #3 - Phishing
- GP4.3 - Growth and Fraud - Case #3 - Phishing
- GP4.3 - Growth and Fraud - Case #3 - Phishing
- GP4.3 - Growth and Fraud - Case #3 - Phishing
- long-term GPG signing key
- long-term GPG signing key
- long-term GPG signing key
- Kama Sutra Spoofs Digital Certificates
- A glimpse of SIGINT 20 years ago
- thoughts on one time pads
- thoughts on one time pads
- thoughts on one time pads
- Face and fingerprints swiped in Dutch biometric passport crack (another card skim vulnerability)
- thoughts on one time pads
- thoughts on one time pads
- serious threat models
- Major Browsers and CAS announce balkanisation of Internet Security
- "doing the CA statement shuffle" and other dances
- "doing the CA statement shuffle" and other dances
- FraudWatch - Chip&Pin, a new tenner (USD10)
- FraudWatch - Chip&Pin, a new tenner (USD10)
- FraudWatch - Chip&Pin, a new tenner (USD10)
- FraudWatch - Chip&Pin, a new tenner (USD10)
- NPR : E-Mail Encryption Rare in Everyday Use
- FraudWatch - Chip&Pin, a new tenner (USD10)
- FraudWatch - Chip&Pin, a new tenner (USD10)
- Meccano Trojans coming to a desktop near you
- Meccano Trojans coming to a desktop near you
- Meccano Trojans coming to a desktop near you
- Creativity and security
- Creativity and security
- Meccano Trojans coming to a desktop near you
- Meccano Trojans coming to a desktop near you
- FraudWatch - Chip&Pin, a new tenner (USD10)
- 4th April, 1984
- Unforgeable Blinded Credentials
- Meccano Trojans coming to a desktop near you
- Creativity and security
- FraudWatch - Chip&Pin, a new tenner (USD10)
- FraudWatch - Chip&Pin, a new tenner (USD10)
- FraudWatch - Chip&Pin, a new tenner (USD10)
- Votes are coins stamped with the Red Queen's head
- Votes are coins stamped with the Red Queen's head
- Creativity and security
- Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
- Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
- Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
- Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
GP4.3 - Growth and Fraud - Case #3 - Phishing
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 3, 2006 11:54 AM
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
MailingList: Financial Cryptography
Daniel A. Nagy wrote:
Actually, I still don't understand why do domain name
registries not provide certs with the domain name. After
l, there's already a hierarchy of trust in place there,
why have a different one (and why trust the other one to
certify this one?)? What would be more authoritative
certification than that of the registry?
ref:
https://www.financialcryptography.com/mt/archives/000609.html
one might conjecture that there are some economic forces in play
... if it was done within dns ... there wouldn't have been
justification for independent business ... it would simply be part of
the existing infrastructure.
the other part is if done within the existing dns operation, there would
have been no justification for PKI, certification authorities, digital
certificates, etc.
basically dns provides real-time authoritative information responses
(and structured for generalized information not just binding of
ip-address to domain name ... but can and does provide various kinds
of other information binding including to domain name).
within the dns real-time authoriative information responses, a public
key implementation would be bound to a domain name ... in addition to
the other information bound to a domain name and provided in a real
time response.
the digital certificate model was designed to provide relying party
with stale, static binding information in stituations where the
relying party had no access to their own local repository of
information and/or online, real-time access to some authoritatve
agency with the information (aka an offline environment)
there is dnssec effort, somewhat backed by the ssl certification
industry to have domain name owners register a public key when a
domain name is registered. currently, a certification authority
requires some identification information in conjunction with an ssl
domain name certificate. the ssl certification authority then can do a
real-time retrieval of the identification information onfile with the
domain name infrastructure. then the certification authority does the
expensive, time-consuming, and error prone task of matching the
supplied identification information with the onfile identification
information.
dnssec would allow the certification authority to request digital
signature on ssl domain name certificate applications. then the
certification authority could do a real-time retrival of the onfile
public key and verify the digital signature ... replacing a
time-consuming, expensive, and error-prone identification matching
process with a much simpler, reliable, and less-expensive
authentication operation.
the catch-22, is if the ssl certification authority industry can start
doing real-time retrivals of onfile public keys ... then the rest of
the world could also ... obsoleting the requirement for ssl domain
name certificates. lots of past postings on ssl certificates and the
ssl certification process
http://www.garlic.com/~lynn/subpubkey.html#sslcert
i've even suggested a drastically simplified and efficient ssl
hand-shaking protocol. the client does a call to dns just like they do
today ... but if there is any registered public key ... they get back
both the ip-address along with any public key and crypto protocol
options piggy-backed on the ip-address response.
then in a single communication with the server, they could transmit
the random session key (encrypted with the server's public key) and
the actual request (encrypted with the random session key) ... no SSL
protocol setup chatter is required.
this could even be done as a udp and/or transaction protocol.
note that SSL over HTTP over TCP is quite expensive. the minimum
packet exchange for just TCP is seven packets ... and then HTTP and
SSL has to ride on top of that ... including all the SSL protocol
setup chatter.
an early reliable "transaction" protocol was VMTP ... which reduced
the 7-packet minimum TCP to 5-packet minimum.
I did a lot of work on XTP ... which included support for reliable
"transaction" protocol in 3-packet minimum exchange. lots of past
posts on XTP
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
aka do dns udp in single round-trip, getting ip-address, public key,
and any ssl crypto options in single roundtrip. then do ssl-like
encrypted request/response transaction with XTP in minimum 3-packet
exchange.
while there was an RFC for vmtp ... rfc1045 ... there was never a RFC
for XTP ... although we did a forey at ISO (but got hung up in the
rule about violating OSI model). there are a couple books written on
XTP ... and I've piles of hardcopy and softcopy stuff.
my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
move down to RFCs listed by section and select TERM (term->RFC#).
in the acryonym fastpath section, select "DNSSEC". this will give you
all RFCs associated with DNSSEC ... aka
domain name system security (DNSSEC )
see also domain name system , domain name system extensions , security
4322 4310 4035 4034 4033 3845 3833 3755 3658 3226 3225 3130 3110 3090
3008 3007 2931 2930 2845 2541 2540 2539 2538 2537 2536 2535 2137 2065
if you are in frames mode, selecting any RFC number will bring up the
RFC summary in the lower frame. as always, selecting the ".txt=nnnn"
field (in an rfc summary) retrieves the actual RFC.
GP4.3 - Growth and Fraud - Case #3 - Phishing
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 3, 2006 01:14 PM
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000609.html
or you could go even further. the prevailing use of SSL is for hiding
account numbers in payment transaction.
the long-time vulnerability for payment transactions was attacker
evesdropping and/or harvesting account numbers and using them in
fraudulent transactions
http://www.garlic.com/~lynn/subintegrity.html#harvest
http://www.garlic.com/~lynn/subintegrity.html#secrets
http://www.garlic.com/~lynn/subintegrity.html#fraud
effectively a form of replay-attack.
the x9a10 standards working group was given the requirement to
preserve the integrity of the financial infrastructure for ALL retail
payments. the resulting protocol was x9.59.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
it had two business rules
1) transactions were strongly authenticated
2) account numbers used in x9.59 transactions would not be valid in
non-authenticated transactions
this is effectively traditional countermeasures for attackers
attempting replay attacks.
with the elimination of the evesdropping/harvesting vulnerability for
replay attacks (fraudulent transactions) the justification for hiding
the account number was drastically reduced.
x9.59 transactions had sufficient protection with simple
authentication for fraud prevention and no longer needed encrypting
and account number hiding to prevent fraud.
customers would register public keys with their accounts (in similar
manner suggested for domain name infrastructure) ... similar to
registering "mother's maiden name" or other authentication
information. the consumer applies their digital signature to the x9.59
transaction and send it on its way. the transaction eventually arrives
at the consumer's financial institution, validates the digital
signature (with the onfile public key), does their other bit of
authentication magic and authorization magic and send off the reply.
no PKI, certification authority and/or digital certificates are
required. in addition, it also eliminates the requirement for SSL
hiding of the account number; just simple authentication and long
understood countermeausures against replay attacks.
the ancillary issue was that there were some other payment protocol
activities going on concurrent with the x9.59.
we had been involved in much of the work on the original payment
gateway with this little client/server startup company that had come
up with SSL (and used for hiding payment transactions)
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
one of the scenarios that we looked at with respect to some of the
PKI/certificate-based payments ... was just the payload size. A PKI
infrastructure has the original transaction, an appended digital
signature, and one or more appended digital certificates (under the
assumption that the receiving party has no prior knowledge of the
signer and/or their public key).
A standard ISO8583 payment transactions runs 60-80 bytes. The common
appended PKI digital certificate of the period ran 4k-12k
bytes. Basically, the PKI-based infrastructure planned on increasing
the transaction payload size by two orders of magnitude (100 times
increase in payload size) with appended PKI overhead ... solely on the
justification that the receiving consumer's financial institution had
no prior relationship with the consumer (which appears to be logical
contridiction).
GP4.3 - Growth and Fraud - Case #3 - Phishing
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 3, 2006 03:06 PM
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#0
http://www.garlic.com/~lynn/aadsm22.htm#1
the other approach to doing the financial transaction account number
vulnerability analysis is using the userid/password metaphor.
bascially an account number is used to select the account, like the
functionality provided by userids. also, like userids, account numbers
are required to be available and used in a large number of different
business processes.
however, the account number is also used to authenticate the
transaction ... i.e. knowledge of the account number is sufficient
authentication in large number of payment transactions. in that use,
the account number is like a password and is vulnerable to
evesdropping, skimming, and/or harvesting. thus such account number
uses is also like a password.
the use of an account number as both a "userid" and a "passwords" may
create an horribly conflicted environment. in past periods, the
industry had created countermeasures to account number guessing
... i.e. as fraud prevention in account number role as password.
however, the advent of evesdropping, skimming, and harvesting attacks
sidestepped the guessing countermeasures and opened the way for replay
attacks (i.e. capturuing a valid value and replaying it).
SSL and various of the PKI-based payment protocols provided
countermeasure to account number evesdropping while transactions were
in-flight. however, one of the long term (preceeding internet use)
attacks against account numbers have been havesting account numbers
from stored information. the stored transaction account information
was required for a large number of business processes where the
account number role is used like a "userid".
old related posting on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61
and findings that continue to show that the leading cause of data
breaches associated with id/account theft involve insiders
http://www.garlic.com/~lynn/aadsm17.htm#38
ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
this gave rise to my past comments that the planet could be buried
under miles of encryption and it still wouldn't prevent account number
leakages. the problem was the dual-use requirements placed on account
numbers for both userid functionality and password functionality and
the radically conflicted processing and protection objectives. The
account number as userid functionality has to be fairly widely
available. The account number as password functionality has to be kept
hidden and confidential. This conflicting requirements leads to
enormous problems and vulnerabilities that can't be addressed by simply
hiding the account number in transit.
the solution by x9.59 retail payment standard eliminated the dual-use
conflict for account numbers. account numbers were solely restricted
to use as userid funtionality. digital signatures were introduced for
(authentication) password functionlity. x9.59 enabled accounts would
not process transactions that didn't have appropriate authentication
(many of the PKI-oriented payment protocols solely addressed hiding
the account number, but still allowed the account number to be skimmed
or harvested and used in non-PKI and non-authenticated transactions).
in this sense the old style accounts are somewhat like ftp/anonymous
or "guest" accounts (except there is attempt to hide the userid)
accounts and the new, x9.59 accounts require authentication independent
of having the correct userid.
with the elimination of account number dual use ... it was no longer
necessary to hide the account number ... since it was only be used for
"userid" functionality.
static data passwords are still subject to evesdropping and replay
attacks ... and therefor are required to be hidden. advantage of
digital signatures for authentication (over static data passwords) is
that they can be evesdropped w/o being vulnerable to replay attacks.
as previously mentioned, a separate issue with some of the PKI-based
payment protocols was the enormous payload bloat (increase in
payload size of one hundred times) introduced by requiring stale,
static, redundant and superfluous digital certificates to
be appended to payment transaction.
going back to fundamental principle of PKI, certification authorities
and appended digital certificates ... is that you have digitally
signed something and prepared to transmit the transaction and the
appended digital signature.
The issue in PKI environment is that the targeted recipient has no
prior information about you and/or has no way of doing online
operation to obtain information about you. So digital certificates
are created that have been certified by independent, well known
parties (where the targeted recipient is believed to have some sort of
trusted relationship). The targeted recipient is believed to trust the
certification authority and therefor the appended digital certificate
with appropriate information about you ... will be trusted (in lieu of
the targeted recipient otherwise having information about you)
However, it takes quite a bit of confused thinking to believe that a
consumer's financial institution has no prior knowledge about their
consumers for which they have created consumer accounts and issued
consumer account numbers. It is even more unbelievable that because it
is believed that a consumer's financial institution has absolutely no
existing relationship with the consumer (for which there is an
account) ... that it justifies bloating a payment transaction payload
size by a factor of one hundred times.
GP4.3 - Growth and Fraud - Case #3 - Phishing
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 4, 2006 12:28 PM
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
MailingList: Financial Cryptography
a PKI certificate-based model assumes that the relying party or
recipient
- 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
http://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
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
can do the identical public key registration as the PKI scenario. the
certificate-less process, just eliminates the manufacturing of a
redundant and superfluous digital certificate and also eliminates the
appending of a redundant and superfluous digital certificate on every
financial transaction sent back to the consumer's financial
institution (as well as avoiding the 100-times payload size bloat).
As mentioned before, neither the SSL nor the PKI-based account hiding
technique actually addressed the major long-term vulnerability of
account numbers (dual-use vulnerability with account number
representing both the userid functionality as well as the password
functionality).
old related posting on security proportional to risk (and the
merchant transaction file)
http://www.garlic.com/~lynn/2001h.html#61
and that continue to show that the leading cause of data breaches
associated with id/account theft involve insiders
http://www.garlic.com/~lynn/aadsm17.htm#38 ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
similarly, the solution to major SSL domain name certificate
vulnerability was the registration of a domain name user's public
key. The trust root for SSL domain name certificate then
changes from the identification information on file with the domain
name infrastructure (and the expensive, error-prone, and time-consuming
identification matching process) to the onfile,
certificate-less public key (and a simpler, more reliable, and
less expensive digital signature verification process).
A certificate-less, SSH-style implementation doesn't
necessarily mean that there has not been any registration process
and/or certification of the public key. It may just mean that there
hasn't been the certificate manufacturing (a term we coined
when we were doing the original payment gateway and auditing these new
operations called certification authorities) process.
http://www.garlic.com/~lynn/aadsm22.htm#0
http://www.garlic.com/~lynn/subpubkey.html#sslcert
GP4.3 - Growth and Fraud - Case #3 - Phishing
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Subject: GP4.3 - Growth and Fraud - Case #3 - Phishing
Date: January 5, 2006 01:42 AM
MailingList: Financial Cryptography
the certificate payload bloat was so enormous for payment protocols
(factor of 100 times) that X9 financial standard group (with a backing
of major PKI forces) started a new work item called digital
certificate compression. the idea was to come up with various
compression techniques to try and get the appended digital certificate
down from several thousand bytes to possibly 300 bytes.
the first thing they talked about doing was eliminating all fields
that were common across all certificates by the same institution.
early on i pointed out that there was a couple of different ways of
addressing the enormous payload bloat of digital certificates in
payment protocols ... aside from eliminating them as being redundant
and superfluous.
a perfectly valid information compression technique was to eliminate
all fields that were already in possession of the relying-party (not
just the fields that were common to all certificates). i quickly
showed that this technique easily achieves zero-byte
certificates. rather than making the rash statement of not appending
stale, static digital certificates to every digitally signed
transaction, i suggested that implementations should instead append
zero byte certificates to every digitally signed payment transaction.
the other mechanism was to use certificate caching echnology ... if
the relying party was known to have previously acquired the consumer's
digital certificate and was to known to have saved it ... then it was
possible to avoid appending the same digital certificate on subsequent
payment transactions ... since it could be shown that the relying
party was guaranteed to already have a copy.
since it was a relying party scenario, the institution being the
registration authority as well as the certification authority; when
the consumer registered their public key with their institution
... the institution would dutifully manufacture a full-fledge digital
certificate and save it in the consumer's account record. then the
institution would return a note to the consumer saying that they were
saving the consumer's digital certificate on behalf of the consumer
... and therefor it was not necessary to actually send the consumer a
copy of their digital certificate ... since it would just result in
the consumer appending the copy to possibly thousands of future
payment transactions and returning it to the financial institution. by
caching the original, the financial institution was saving the
consumer enormous amounts of bandwidth and processing. if the consumer
wanted, they could append a short note to future digitally signed
payment transactions stating that the digital certificate was already
on file (in many cases, the digital certificate on file wouldn't even
be a copy, but the original).
numerous past post discussing the enormous benefits of creating
zero-byte digital certificates with advanced information compression
technology
http://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
long-term GPG signing key
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: long-term GPG signing key
Date: Wed, 11 Jan 2006 13:09:38 -0700
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Ian G <iang@xxxxxxxx>, "Travis H." <solinym@xxxxxxxx>,
cryptography@xxxxxxxx
Perry E. Metzger wrote:
Even in totally ordinary circumstances it is important to have very
strong signing keys. Your comments were insupportable.
there is a somewhat separate issue having to do with security
proportional to risk. minor old posting:
http://www.garlic.com/~lynn/2001h.html#61
the security acronym PAIN
P ... privacy (or sometimes CAIN and conficentiality)
A ... authentication
I ... integrity
N ... non-repudiation
part of the problem is that sometimes there is confusion between
digital signatures and human signatures (implying read, understood,
agrees, approves, and/or authorizes).
the technology is asymmetric keys .... involving a pair of keys, what
one key encodes, the other key decodes (differentiates from symmetric
key encryption where the same key is used for encryption and
decryption).
there is a business process commonly referred to as public key where
one key of a asymmetric key pair is identified as public and made
available. the other key is identified as private, kept confidential
and never divulged.
there is a business process called digital signatures where a hash of
some message or document is computed and then encoded. the
message/document is sent off with the appended digital signature. the
recipient recomputes the hash of the message/document and decodes the
digital signature with the corresponding public key. if the two hashes
compare, then the recipient (or relying party) can assume:
- 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
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
that happen to be credit card transactions where the account owner has
a credit limit of $1000, all transactions are online against the
account, the account public key can be deactivated when there appears
to be fraud and, to the consumer the frauulent transactions, can be
reversed (leaving the consumer with a maximum $50 exposure).
the existing infrastructure has no real authentication operation except
for attempting to maintain the account number as a shared-secret (which
implies that the account number ... rather than any public key ... has
to be deactivated & replaced when there has been compromise):
http://www.garlic.com/~lynn/subintegrity.html#secret
some postings on account number skimming/havesting
http://www.garlic.com/~lynn/subintegrity.html#harvest
some postings on fraud & vulnerabilities
http://www.garlic.com/~lynn/subintegrity.html#fraud
compared to some of the other payment card operations that specified
public key authentication ... x9.59 allowed for
1) digital signature authenticated transactions
2) account number used in authenticated transactions could not be
skimmed and used in non-authenticated transactions (which some of the
other specifications allowed) ... basically countermeasure to form of
replay attacks and countermeasure for having to treat account number as
shared-secret.
the basic issue in both (digital signature) signing keys and
encryption keys is what is the risk from a compromise and based on
that risk you can determine the level security required.
another consideration is the overall infrastructures. for many of the
online e-commerce operations ... an ECC 163-bit signing key probably
has a lot higher security strength than the rest of the infrastructure
used to protect the signing key and/or the environment where the
digital signature is applied. from an attackers standpoint that means
that it is probably cheaper/easier to attack the infrastructure to
capture the signing key ... than to try a brute-force attack on the
signing key (and all of these other attacks are applicable regardless
of the strength of the signing key). there may also be attacks on
other parts of the infrastructure ... getting the financial
institution to register a new public key (belonging to the attacker)
or getting a certification authority to issue a new certificate with
the attacker's public key in the name of the victim. some of these
other operations may be currently weak because the claim is that they
aren't currently the weakest link in overall infrastructure.
there may be other trade-offs. it is possible to get reasonably priced
14443 contactless tokens that can do ecc 163-bit digital signing in
subsecond time that may be desirable in various POS or transit
turnstyle operations. going to larger key sizes may exceed both the
power requirement and the elapsed time requirement (in contact token
operatin you can someimes trade-off peak power draw against onger
elapsed time). The case can be made in some scenarios ... that the
longest possible keylength be chosen if the power and elapsed time
requirements aren't a major factor. However, there can be environments
where power and elapsed time requirements may justify choosing a
shorter keylength (within the context of the overall environment)
one of the things that payment card infrastructures have the ability
to do is a real time risk evaluation on a per transaction basis and
pass judgement on a wide variety of factors which might include
... key length, whether there is a certifified token protecting the
signing key and what is the evaluated integrity of that token, what
kind of terminal and merchant is used for the digital signing
environment, the physical location of the signing, past consumer
transaction history, past terminal transaction history, etc. one might
imagine financial institution having different minimum token and key
length requirements for different kinds of accounts and/or different
kinds of transactions (based on factors like overall risk and the
relative security strength in which such tokens and signing keys
operate).
you might some authorities setting the requirements don't understand
the overall risk and infrastructure issues ... they can always go for
the maximum available for everything ... even if some of the specified
requirements don't make any sense in a particular overall
infrastructurt. the other may be that the infrastructure has no means
of differentiating and authorizing at different levels of risk ... so
that the requirements have to mandate the maximum strength for all
components, always assuming the worst case risk.
there may be a lot higher risk with a (digital signature) signing
public key gets confused with human signatures ... which then may
carry with it the implicattion of a human read, understood, agrees,
approves, and/or autherirzes the contents of what is signed, the risk
exposure might also be greater is if the overall infrastructure is an
offline environment that is totally dependent on digital certificates
and PKI operation as opposed to a real-time, online environment that
can take into account a lot larger numgber of factors (including
aggregation of past transactions).
long-term GPG signing key
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: long-term GPG signing key
Date: Sat, 14 Jan 2006 12:30:25 -0700
To: Guus Sliepen <guus@xxxxxxxx>, cryptography@xxxxxxxx
Guus Sliepen wrote:
By default, GPG creates a signing key and an encryption key. The signing
key is used both for signing other keys (including self-signing your own
keys), and for signing documents (like emails). However, it is possible
to "split" the signing key into a master key that you only use to sign
other keys, and a key dedicated to signing documents. You can revoke the
latter key and create a new one whenever you want, the master key is
still valid. Also, when people sign your key, they sign your master key,
not the subkeys. The signatures you accumulated will also still be
valid. You can also keep the master key safely tucked away on an old
laptop that you keep in a safe, and only export the subkeys to your
workstation. That way the master key is very safe.
as in previous post ... i assert that fundamental digital signature
verification is an authentication operation
http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing keys
and doesn't (by itself) carry with it characteristics of human
signature, read, understood, agrees, approves, and/or authorizes.
the PKI & CA hiearchical infrastructures does tend to add those
attributes to digital signature operations ... creating an
equiivalence between certification digital signatures (and the private
keys that produce such digital signatures) and the validity of the
information being certified.
if you are starting to create a class of private keys that start to
carry the attribute of whether something is true or not (i.e. the
information being certified) ... then there can start to become some
confusion between the difference between the private key as an
authentication mechanism and the use of the private key as whether
something is true or not.
I would assert that authentication private keys can be treated like a
much better password technology ... not having various of the
shared-secret vulnerabilities and other shortcomings.
http://www.garlic.com/~lynn/subintegrity.html#secrets
it is when you start equating private keys with certification and
truth characteristics that you move into a completely different risk
and threat domain.
the other foray into embellishing private keys and digital signatures
with human signature type characteristics was the non-repudiation
activity. however, it is now commoningly accepted that to embellish
digital signatures with non-repudiation attributes requires a whole
lot of additional business processes ... not the simple operation of
generating an authentication digital signature.
the whole scenario of digital signing of public keys ... is not a
matter of the entity performing the digital signing doing an
authentication operation ... but that the entity is certifying the
truth of some value ... typically related to the public key. that is a
whole business process infrastructure that has to be layered on top of
digital signatures (in much the same way to actually achieve
non-repudiation a whole business process infrastructure has to be
created that is built above any authentication digital signature).
the other characteristics is that stale, static certification
... paper or digitally signed electronic bits ... are characteristic
of the offline age ... where an entity could present the certificate
representing the truth of some information; as opposed to the relying
party having their own access to the truth of the same information. in
the transition to an online world, it is becoming less & less coming
that relying parties won't have access to the truth of some piece of
information (making certificates and credentials less and less
meaningful). the corollary is that digitally signed certificates and
private keys embellished with certification and truth characteristics
become less and less meaningful.
any embellishing of digital signatures with human signature attributes
(i.e. read, understood, agrees, approves, and/or authorizes) in
addition to straight forward authentication, can also lead down the
dual-use vulnerability path
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
long-term GPG signing key
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: long-term GPG signing key
Date: Sat, 14 Jan 2006 15:17:05 -0700
To: Guus Sliepen <guus@xxxxxxxx>, cryptography@xxxxxxxx
Guus Sliepen wrote:
It depends on how it is used. For example, when I sent this email, I
typed in the passphrase of my PGP key, authorising GnuPG to create a
signature for this email. This comes very close to "human signing". I
read, understood, approve etc. with the contents of this email.
If assymetric cryptography is used to automatically sign a credit card
transaction without the user having to do more than click a button, then
I agree that in that situation, the digital signature is not the same as
a human signature.
but as in some of the PKI forays into non-repudiation and human
signatures ... there was no way for a relying party to determine the
difference ... and in the previous thread of digital signature
dual-use vulnerability, this can open up fraud.
at one point, some were assuming if there was a digital certificate
with the non-repudiation flag set, then the digital signature
indicated human signature (read, understood, agrees, approves, and/or
authorizes). however, nothing in various PKI protocols provided for
proving which digital certificate was actually appended to a
particular digital signature (appending a non-repudiation digital
certificate might imply the creation of some obligation associated
with a digital signature used as a human signature; however there was
no protocol provisions for establishing which form of digital
signature was actually intended and/or which digital certificate was
actually appended to any particular operation).
the dual-use vulnerability may have an environment where servers nominally
transmit random data for signing (one of the possible countermeasures
for replay attack) and the person generates a digital signature on the
random data w/o having looked at the data (assuming purely
authentication operation). the other party has actually substituted
some sort of valid text in place of the random data and then asserts
that the person has performed the digital signature implying a human
signature (read, understood, agrees, approves, and/or authorizes) as
opposed to implying pure authentication operation.
the crook may attempt to further substantiate the fraudulent claim by
producing a digital certificate (for the corresponding public key)
with the non-repudiation bit set (and PKI protocols lack provisions
for differentiating which, of possible several, digital certificates
might actually have been attached).
the possible dual-use for digital signatures then may lead to enormous
ambiguity since the basic technology only provides for authentication
... and w/o significant additional business processes it is
difficult to differentiate digital signatures used for purely
authentication purposes and the grossly embellished purposes
associated with human signatures.
any embellishing of digital signatures for human signature purposes,
in turn, creates significant additional risk than straight-forward
authentication.
a basic issue isn't what you intended when you caused a digital
signature to be created ... but what can any relying-party reasonably
expect that you intended ... and what can the relying-party reasonably
rely on.
then, if there is any possible ambiguity as to what you may have
intended when a digital signature was created, can an attacker use the
existence of such ambiguity to perpetrate fraud (aka dual-use
vulnerability).
Kama Sutra Spoofs Digital Certificates
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Kama Sutra Spoofs Digital Certificates
Date: Tue, 24 Jan 2006 21:53:09 -0700
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
Kama Sutra Spoofs Digital Certificates
http://www.informationweek.com/windows/showArticle.jhtml?articleID=177103418
The Kama Sutra worm can fool Windows into accepting a malicious ActiveX
control by spoofing a digital signature, a security company said Tuesday.
.. snip ..
A glimpse of SIGINT 20 years ago
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A glimpse of SIGINT 20 years ago...
Date: Thu, 26 Jan 2006 13:56:40 -0700
To: cryptography@xxxxxxxx
CC: Perry E. Metzger <perry@xxxxxxxx>
Perry E. Metzger wrote:
This is a couple of weeks old, but it appears that, by accident, a lot
of information on the targets and methods being used for
US/Australian/NZ SIGINT about 20 years ago has come to light as the
result of the release of a late New Zealand Prime Minister's papers.
http://www.stuff.co.nz/stuff/print/0,1478,3540743a6005,00.html
Among other things:
The report lists the Tangimoana station's targets in 1985-86 as
"French South Pacific civil, naval and military; French Antarctic
civil; Vietnamese diplomatic; North Korean diplomatic; Egyptian
diplomatic; Soviet merchant and scientific research shipping; Soviet
Antarctic civil. Soviet fisheries; Argentine naval; Non-Soviet
Antarctic civil; East German diplomatic; Japanese diplomatic;
Philippine diplomatic; South African Armed Forces; Laotian diplomatic
(and) UN diplomatic."
The station intercepted 165,174 messages from these targets, "an
increase of approximately 37,000 on the 84/85 figure. Reporting on the
Soviet target increased by 20% on the previous year".
recent posting and glimpse of public key crypto 20 years ago
http://www.garlic.com/~lynn/2006.html#30
thoughts on one time pads
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Fri, 27 Jan 2006 14:11:27 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>, Dave Howe <DaveHowe@xxxxxxxx>
John Denker wrote:
One drawback with this is that you have to destroy a whole
disk at a time. That's a problem, because if you have a
whole disk full of daily keys, you want to destroy each
day's key as soon as you are through using it. There
are ways around this, such as reading the disk into volatile
RAM and then grinding the disk ... then you just have to make
sure the RAM is neither more volatile nor less volatile than
you wanted it to be. That is, you use the disk for *distribution*
but not necessarily for intermediate-term storage.
is there any more reason to destroy a daily key after it as been used
than before it has been used?
one of the attacks on the stored-value gift cards has been to skim the
cards in the racks (before they've been activated) ... and check back
later to see which cards are gone.
i was standing at grocery store checkout last week ... apparently it
was the store manager ... one of the other employees came up with a
gift card that somebody had bought before xmas and gave as a
present. they had come back complaining that there was no money
credit/left in the account. it could have simply been an computer foul-up
... and then again, it could have been somebody had skimmed the card,
waited and then drained the account.
thoughts on one time pads
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Sat, 28 Jan 2006 15:29:22 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>, Dave Howe <DaveHowe@xxxxxxxx>
John Denker wrote:
That indicates a gross lack of tamper-evident packaging, as discussed
above. The store should never have activated a card that came from a
package that had been tampered with.
if you have seen many of the gift cards in racks at grocery stores ...
they can be skimmed w/o any tampering needed (many with no packaging at
all). it might be better that they were shipped in some sort of
packaging that would require tampering in order to skim.
i think that the conventional wisdom was that the cards were (nearly)
worthless until activated (and so why would anybody bother with a
worthless card).
thoughts on one time pads
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Sat, 28 Jan 2006 15:50:16 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>, Dave Howe <DaveHowe@xxxxxxxx>
John Denker wrote:
-- The best way to _protect_ a key after it has been used is to destroy
it.
-- For keys that have yet been used, a sufficient scheme (not the only
scheme) for many purposes is to package the keys in a way that is
tamper-resistant and verrry tamper-evident.
ref:
http://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads
periodically there was some discussion about institutional-centric
tokens vis-a-vis person-centric tokens ... in one case specifically
with respect to being able to replace magstripe payment cards with
tokens.
in the person-centric token scenario, the person can choose to have a
single token that they could use for all authentication purposes,
including all accounts (or choose how many tokens they want and which
purposes each token is used for).
at one point, there were counter arguments that a single card per
account (the current mechanism) was much preferred because of the
lost/stolen card problem. the problem is that the prevailing threat
model for lost/stolen cards is the purse or wallet containing all
cards (as opposed to individual cards).
the person-centric model at least would allow a person to replace all
cards (subject to common threat model) with a single token.
a major issue with cdrom one-time pads would be somebody skimming the
whole cdrom.
destroying keys as they are being used would appear to only be a
countermeasure to theft of the cdrom (in which case it is apparent
that unused pads are compromised and should be eliminated). however,
skimming the cdrom might not leave any trace that unused pads have
been compromised ... which turned out to be the issue in the gift card
skimming compromise.
Face and fingerprints swiped in Dutch biometric passport crack (another card skim vulnerability)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Face and fingerprints swiped in Dutch biometric passport crack (another card skim vulnerability)
Date: Mon, 30 Jan 2006 08:53:29 -0700
To: cryptography@xxxxxxxx
Face and fingerprints swiped in Dutch biometric passport crack
http://www.theregister.co.uk/2006/01/30/dutch_biometric_passport_crack/
The crack is attributed to Delft smartcard security specialist
Riscure, which explains that an attack can be executed from around 10
metres and the security broken, revealing date of birth, facial image
and fingerprint, in around two hours.
.. snip ..
some recent skimming posts
http://www.garlic.com/~lynn/aadsm20.htm#1 Keeping an eye on ATM fraud
http://www.garlic.com/~lynn/aadsm20.htm#18 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
http://www.garlic.com/~lynn/aadsm20.htm#23 Online ID Thieves Exploit Lax ATM Security
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#15 [Clips] Contactless payments and the security challenges
http://www.garlic.com/~lynn/aadsm21.htm#18 'Virtual Card' Offers Online Security Blanket
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
thoughts on one time pads
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Tue, 31 Jan 2006 09:46:02 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>
John Denker wrote:
It is worth your time to read _Between Silk and Cyanide_.
That contains an example of somebody who thought really
hard about what his threat was, and came up with a system
to deal with the threat ... a system that ran counter to
the previous conventional wisdom. It involved protecting
keys before use and destroying them after use.
ref:
http://www.garlic.com/~lynn/aadsm22.htm#10 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#11 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm22.htm#13 Face and fingerprints swiped in Dutch biometric passport crack (another skimming vulnerability)
if you have a scores or hundreds of one-time pads (or any other static
secrets) on a cd .... and the vulnerability is skimming ... then if
the already used pads are destroyed as countermeasure to skimming
... the unused pads that are also on the same cd are also vulnerable
to the same skimming. say the cd was skimmed before any pads were used
... then there hasn't yet been any destroyed pads. supposedly if you
provide protection sufficient for the unused pads ... then that should
be protection for the used pads also (although there always is the
school of thot that more security is always better).
destroying just the one time pads on a cd is countermeasure to theft
... since the theft of the cd hopefully prevents the unused pads from
being used (at least by you), there potentially is vulnerability that
the thief might be able to use the unused pads in some sort of attack.
the issue is that having both used and unused pads on the same CD
creates a potential common vulnerability of everything on the same CD
(which are in different states). once all pads have been used ... then
the whole CD represents a common vulnerability state ... and the whole
CD can be destroyed.
thoughts on one time pads
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: thoughts on one time pads
Date: Tue, 31 Jan 2006 10:20:41 -0700
To: cryptography@xxxxxxxx
CC: John Denker <jsd@xxxxxxxx>
John Denker wrote:
I forgot to mention in my previous message:
It is worth your time to read _Between Silk and Cyanide_.
That contains an example of somebody who thought really
hard about what his threat was, and came up with a system
to deal with the threat ... a system that ran counter to
the previous conventional wisdom. It involved protecting
keys before use and destroying them after use.
an open question is whether preventing anybody from accessing the cd
for skimming is also sufficient for preventing anybody from accessing
the cd for theft. this has some analogy to tamper-evident vis-a-vis
tamper-proof.
obviously theft leaves more tell tail trails (aka tamper-evident).
then, does the countermeasures for skimming (tamper-proof) have to be
more stringent than countermeausures for theft (tamper-evident).
destroying used pad is countermeasure for all kinds of access of the
used pad. however destroying used pads still leaves vulnerability of
skimming the unused pads (on the same cd). if the countermeasures for
skimming the unused pads (tamper-proof) is sufficiently high ... then
that may also be adequate for all kinds of access to the used pads on
the same cd.
but as mentioned ... there are also the people of the school of thot
that more security is always better.
serious threat models
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: serious threat models
Date: Sat, 04 Feb 2006 11:42:06 -0700
To: cryptography@xxxxxxxx
CC: Perry E. Metzger <perry@xxxxxxxx>,
Jaap-Henk Hoepman <jhh@xxxxxxxx>
Perry E. Metzger wrote:
All phone switches, thanks to the US government's CALEA rules, are
equipped with software that makes espionage easy. Whether that
software was abused in this instance, I do not know, but I will point
out that any switch sold in the US -- which is to say most switches
that exist -- has software available (but not necessarily installed)
to tap people's phones in a manner not entirely unlike what happened
to the high government officials in Greece.
Yet again, I point out John Gilmore's warning that once you make law
enforcement "convenient" by creating privacy invading technologies,
you have very little control over who ultimately comes to use those
technologies. It will not only be the good guys who get access to
them, and even the guys who have legitimate access will not always be
good guys.
the off-site terminal program for accessing systems online, reading
email, etc, while on the road ... early 80s ... a vulnerability
analysis was done and one of the biggest identified threats was hotel
PBXs (frequently the room was unlocked and anybody could walk in). as
a result there was work done on custom encrypting (2400)
modem. basically did session key exchange on connection, so that all
transmission was encrypted.
i was amazed in the 90s with the growing use of laptops and online
access (traveling road warriors) and the number of people that seemed
oblivious to the security issues. insecure practices that was forboten
from at least 1980 (although i had online access at home for ten years
prior to the encrypting modems, starting march 1970)
Major Browsers and CAS announce balkanisation of Internet Security
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Major Browsers and CAS announce balkanisation of Internet Security
Date: February 22, 2006 12:41 PM
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000662.html
this is the scenario where authentication has been allowed to get
really sloppy and the solution is strong identification ... the
individual scenario is having your complete lineage stapled to your
forehead.
in general, identification scenarios involve being able to blame the
correct entity after something bad happens (which may act as a
deterrent) ... where-as, authentication scenarios typically are aimed
at prevention.
the problem is that authentication requires that the entity being
authenticated has some context for the entity doing the
authentication; if that context doesn't exist ... then you fall back
to some sort of detailed identification and hope that there is some
information that provides basis for meaningful context.
during the x9.59 standards activity in the 90s, there was some
investigation into carrying trademarks in certificates ... the
certification authorities would only include trademarks for the
entity that has registered the trademark with the appropriate
gov. agency. hopefully the trademarks provide some meaningful context
for the end-user ... and there are existing legal recourse for mis-use
of trademarks.
an issue here then becomes similar to my oft repeated scenario for SSL
domain name certificates ... the certification authorities still have
this time-consuming, error-prone and expensive identification process
of making sure that the entity applying for the certificate is the
same as the entity registered with the appropriate authoritative
agency (responsible for whatever the certificaition authorities are
certifying for the certificate).
then somebody has the brilliant idea that when there is some
registration with some authoritative agency ... that the registration
entity also register their public key. then the certification
authorities require that certificate applications be digitally
signed. then the certification authorities can do a real-time
retrieval of the registered public key from the authoritative agency
and change an expensive, error-prone and time-consuming identification
operation (i.e. the entity applying for the certificate is the same as
the entity registered for the information being certificate) into a
more reliable, less expensive, and simple authentication process.
the issue then is that if certification authorities can do real-time
retrieval of public keys from authoritative agencies responsible for
the information being certified ... why can't the general public also
do real-time retrieval of the same public keys ... and be able to
perform their own authentication ... rather than requiring
certification authorities to do such authentication on their behalf
and creating these things called digital certificates that are a
representation of claims about (certification authorities) having
performed some set of (authentication and/or identification) business
processes.
an issue has been that public keys haven't been in general use ... so
that authoritative agencies that are actually responsible for the
information have no reason to require the registration of public keys
from entities (as part of their general process). however, if public
keys were to become generally used ... as in everybody applying for a
digital certificate (from a certification authority), then there is an
increasing expectation that entities will have public keys (for
instance, one is required for a digital certificate). given sufficient
expectation of public keys ... then the real authoritative agencies
responsible for registered information can ressonably start to expect
that they could also register public keys along with the rest of the
information. then everybody being able to directly access these
authoritative agencies actually responsible for registered inforation
... could perform their own real-time retrieval of public keys and
their own authentication process (w/o requiring certification
authorities as intermediaries).
A recent posting on the privacy side of this process (which is
supposedly side-stepped when you are talking about identification of
corporations and institutions ... as opposed to the individual)
http://www.garlic.com/~lynn/2006c.html#31 Worried about your online privacy
past postings about the effort to have public keys registered along
with the registration with other information with various
authoritative agencies
http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#24 Broken SSL domain name trust model
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2001l.html#22 Web of Trust
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003d.html#29 SSL questions
http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
http://www.garlic.com/~lynn/2004b.html#41 SSL certificates
http://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005i.html#3 General PKI Question
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#9 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
"doing the CA statement shuffle" and other dances
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 5, 2006 08:41 PM
Subject: "doing the CA statement shuffle" and other dances
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000672.html
when we were doing the original payment gateway as part of the
commerce server doing payment transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
looked at some number of additional things that a certificate could
represent, in addition to straight-forward ssl domain name
certification.
recent post about ssl domain name certificate process being
compromised because original design had the user typing in the url and
then the server supplied certificate matched the typed in URL implied
that the server the user thot they were talking to was the server they
were talking to (implicit was belief that the end-user had
understanding between some entity and their URL)
http://www.garlic.com/~lynn/2006d.html#28
as the environment evolved to users simply clicking on buttons or
other things (potentially supplied by an attacker) ... the ssl domain
name certificate process just came to mean that any attacker was whoever
their URL claimed them to be
our proposals about including more detailed checks on e-commerce
merchants (possibly including things like fbi background checks on all
employees) didn't catch on (also mentioned in the above post).
part of the issue was financial justification for doing the additional
checking. a merchant/acquiring financial institution already does a
fairly detailed check on any credit card accepting merchant (since
part of a merchant/acquiring financial institution
sponsoring/certifying a merchant for accepting credit card
transactions ... includes taking financial liability for the
merchant).
there was an issue with whether an end-user could trust an unknown
merchant. the e-commerce activity was highly skewed with the majority
of transactions occuring with a few well known and well branded
websites, frequently repeat business. A small percentage of total
e-commerce activity was spread across the vast number of websites
... each website only performing a few transactions each. The high
volume merchants didn't need anymore trust ... since they had the
brand and repeat business. The low volume merchants couldn't justify
paying more for trusted certification ... other than what they were
already paying to their merchant/acquiring financial institution
as part of credit card acceptance certification.
this was still in the days when it was assumed that the user was
typing in the URL and was familiar with the entity and their respective
URL
the evoluation came with the disconnect with what the users perceived
to be entities and clicking on arbitrary strings that provided the URL
to the browsers. This created a disconnect between what the user
perceived to be the entity and the URL supplied to the
browser. Attackers could provide things to click on that claimed to be
some well-known entity, but actually generated some totally unrelated
URL. Then the attacker only had to provide a certificate that proved
that they were who the URL claimed they were (as opposed to any
textual claims as to who they were).
So there possibly are a couple different countermeasures to this
vulnerability/exploit. One is to create some variety of trusted
"clicks" (which have evolved as a substitute for actually typing in
the URL). As part of creating trusted "clicks", there is some user
involvement in establishing the relationship between who the user
thinks the entity represented actually is, the "trusted" click, and
the resulting URL (which was implicit in the original SSL model that
assumed the user would be typing in the URL value and understood the
relationship between some entity and their URL).
An alternative is some sort of high assurance certificate and some
browser visual indication when the browser is dealing with a high
assurance certificate (as opposed to any run of the mill certificate).
The high assurance certificates don't eliminate the disconnect for
end-users where some text can claim that clicking will invoke one
thing ... but actually invokes something else different (the only
thing that ssl domain name certificates does is prove that you are who
your URL claims you to be ... as opposed to what any text surrounding
a click may claim you to be).
Implicit is an assumption that attackers won't be able to obtain a
high assurance certificates (and all the entities that can obtain high
assurance certificates won't involve themselves in impersonations).
to some extent the certificate-based model is that the end-user needs
to have no local support infrastructure ... that it can all be
supplied by institutional entities.
the "trusted" click model assumes that the end-user has some sort of
local support infrastructure ... for recording and preserving their
"trusted" clicks. "trusted" click model could even allow clicking on
externally supplied clicks ... and having the browser tell you whether
it mapped to a trusted click entry and who was the entity associated
with the entry (even visual clues similar to that proposed for high
assurance certificates).
note this is effectively similar/same as earlier post on "trusted"
bookmarks:
http://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model
"doing the CA statement shuffle" and other dances
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 6, 2006 03:46 PM
Subject: "doing the CA statement shuffle" and other dances
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000672.html
http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
from the end-user standpoint, the "trusted click" paradigm, using
something analogous to bookmarks, can be quite similar to cellphone
phone books (using caller-id to maps to different ring tones) or email
address books (where spam blockers may rate incoming different if the
origin address is in the address book).
that doesn't address spoofing the origin email address or spoofing the
caller-id ... but in the web paradigm, basic ssl is used to catch that
type of spoofing.
the current issue is the disconnect with the click paradigm ... where
users are presented with to something to click ... and attempts are
made to obfuscate the URL domain name (SSL provides the connection
between the URL domain name and the website ... but the click paradigm
allows for a disconnect between the end-user and the actual URL domain
name coming off the click).
digital certificate cps, gov. legislation, and audits can be viewed as
attempts to get around the TTP/CA business model being alien to
standard business operations. In standard business operations, the
relying party has business relationship with the certifying agency and
typically there is some exchange of value (implicity or explicity
contract). In the typical TTP/CA business model there is no business
relationship and/or obligation between the CA and the relying
parties. CPS, gov. legislation and audits are approaches that attempt
to provide a sense of comfort for relying parties in certifications
performed by CAs (where it doesn't otherwise exist in normal business
practice).
GSA addressed this in the Federal PKI by signing contracts with all
approved certifying agencies issuing digital certificates
.... essentially making them agents of GSA (for issuing digital
certificates). Then then federal gov., as relying party, could rely on
the issued digital certificates because of their (gsa) contract with
the certification authorities.
note in previous comments, theoritical use of digital certificates is
by relying parties where they have no information about the subject
entity and/or no (other) way of obtaining such information. in the
digital certificate analogy to letters of credit/introduction, the
relying party (when there was no other means of obtaining information)
could record information from the letters of credit/introduction in
their local repository. typically a letter of credit/introduction
wouldn't be repeatedly presented on every interaction, but recorded
locally. the local record is then used for future interactions.
so a local trusted repository (bookmarks, public key repository,
address book, phone book, etc) is used to record information about
interactions. when no other information is readily available (either
locally or via direct contacts with reputable agencies ... in the
domain name case, it could be direct contract with the domain name
infrastructure and retrieving registered public key at the same time
registered ip-address is retrieved), then individual's local
repository might be populated on first-time interaction between two
total strangers with information supplied by digital certificate.
Paradigm that repeatedly presents such credentials on every
interaction typically assume that the relying party has no ability to
maintain local repository (or past information).
The scenario of acquiring/merchant financial institutions implicitly
certifying merchants that can perform credit card transactions,
involves contracts between consumer and their consumer/issuing
financial institution, the consumer/issuing financial institution and
the associations, the associations and the acquiring/merchant
financial institution, as well as the acquiring/merchant financial
institution and the merchant. this series of contracts creates
obligations between the consumer and the merchant. furthermore, the
acquiring/merchant financial institution stands behind the merchant
(taking financial liability), and in return takes a percentage of
every financial transaction.
In the title insurance scenario ... the relying party (consumer) pays
the title insurance company for the certification (direct business
contract between the relying party and the certification agency).
As mentioned, in the typical TTP/CA business operation there is no
direct contractual relationship between the relying party and the
certification agency.
slight drift, part of thread on caller id "spoofing"
http://www.garlic.com/~lynn/2006d.html#31 caller id "spoofing"
which is the analogy between the URL and the webserver and is directly
addressed by ssl domain name certificates ... which is different than
the vulnerability created with the browser "click" disconnect. lots of
past posts about ssl domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
for even more drift, a recent posting about frequent semantic
confusion the result of having the word "signature" occur in both the
terms "human signature" and "digital signature"
http://www.garlic.com/~lynn/2006d.html#34 When *not* to sign an e-mail message?
FraudWatch - Chip&Pin, a new tenner (USD10)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 8, 2006 10:53 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000673.html
it has actually gone thru a number of generations ... and somewhat is
starting to look a little more like x9.59
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
see the discussion here (slight access problem, so had to resort to
the wayback machine)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
with earlier version having gotten the label yes card in the UK
press (see last paragraph in above).
early x9.59 and chip&pin work were going on about the same time. x9.59
looked at straight-forword authentication of the transactions
... while chip&pin has somewhat gone thru a number of iterations starting
to converge on the idea of actually authenticating the transaction (as
opposed to various mechanism possibly authenticating separately from
doing the transaction).
misc. past posts mentioning yes card:
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004j.html#44 Methods of payment
http://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
FraudWatch - Chip&Pin, a new tenner (USD10)
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 10, 2006 02:33 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
events this week may be bringing more attention to transition away
from implementations with skimming, harvesting, and/or MITM
vulnerabilities. small roundup of this week's new articles
Citigroup blocks cards in three nations after breach
http://www.marketwatch.com/News/Story/Story.aspx?guid=%7B4CAA5EFD%2DE932%2D4D14%2D8279%2D03D2446352C9%7D&siteid=mktw&dist=moreover
International Citibank Customers Shaken By Data Breach
http://www.banktech.com/aml/showArticle.jhtml?articleID=181502448
International Citibank Customers Shaken By Data Breach
http://www.securitypipeline.com/news/181502240
Citibank Data Breach | International Citibank Customers Shaken By Data Breach
http://www.informationweek.com/showArticle.jhtml?articleID=181502068
Citi Blocks Some Debit Cards After Breach
http://www.smartmoney.com/bn/on/index.cfm?story=ON-20060308-000922-1159&nav=pf_hp
Citibank cards pulled after network breach
http://www.networkworld.com/news/2006/030706-citibank-network-breach.html
Citibank blocks ATM cards after retailer breach
http://www.finextra.com/fullstory.asp?id=15014
Citibank Data Breach
http://www.compliancepipeline.com/news/181502758
Citibank probes ATM withdrawals, cites potential U.S. 'retailer breaches'
http://www.computerworld.com/securitytopics/security/story/0,10801,109308,00.html
As Banks Reissue Debit Cards, Experts Warn of More Compromises
http://www.digitaltransactions.net/newsstory.cfm?newsid=877
Debit card fraud spree linked to security breach
http://software.silicon.com/security/0,39024655,39157043,00.htm
Citibank Confirms Fraud in Canada, UK, Russia Linked to Breach
http://www.eweek.com/article2/0,1895,1934988,00.asp
Debit Card Fraud Tied to OfficeMax Breach
http://www.eweek.com/article2/0,1895,1935677,00.asp
Debit card fraud outbreak raises questions about data breach
http://www.computerworld.com/industrytopics/retail/story/0,10801,109427,00.html
IBNLive : PAN card fraud busted in Mumbai
http://www.ibnlive.com/article.php?id=6584§ion_id=7
E-Fraud | PIN Scandal 'Worst Hack Ever'; Citibank Only The Start
http://www.informationweek.com/news/showArticle.jhtml?articleID=181502474
US banks fall victim to large-scale hacking and skimming fraud
http://www.finextra.com/fullstory.asp?id=15030
Citibank uncovers debit card fraud
http://www.orlandosentinel.com/business/chi-0603090170mar09,0,3699639.story?coll=orl-business-headlines
Citibank uncovers debit card fraud
http://www.sun-sentinel.com/business/local/chi-0603090170mar09,0,4638004.story?coll=sfla-business-headlines
Citibank uncovers debit card fraud
http://www.chicagotribune.com/technology/local/chi-0603090170mar09,1,1026651.story?coll=chi-technologylocal-hed
PINs no obstacle for debit card thieves
http://msnbc.msn.com/id/11731365/
PINs no obstacle for debit card thieves
http://www.msnbc.msn.com/id/11731365/
Huge ATM Scam May Be Global in Scope
http://www.14wfie.com/Global/story.asp?S=4610973&nav=3w6o
Citibank card fraud - magnetic strip to blame?
http://www.silicon.com/financialservices/0,3800010322,39157105,00.htm
Debit Card Fraud Jumps
http://www.accountingweb.com/cgi-bin/item.cgi?id=101885
Officials: ATM PINs Stolen On Massive Scale
http://www.thewbalchannel.com/consumeralert/7860927/detail.html
Citibank responds to ATM fraud concerns
http://www.atmmarketplace.com/news_story_25260.htm
Card Skimming Is ATM Industry's Biggest Fraud
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1141822818622215212&block=
New debit card fraud tied to West Coast case
http://news.com.com/New+debit+card+fraud+tied+to+West+Coast+case/2100-1029_3-6047100.html?tag=nefd.top
New debit card fraud tied to West Coast case
http://news.zdnet.com/2100-9595_22-6047100.html
New debit card fraud tied to West Coast case
http://news.com.com/2100-1029_3-6047100.html?part=rss&tag=6047100&subj=news
New debit card fraud tied to West Coast case
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=19548
Fraudsters target Citibank - Breaking
http://www.smh.com.au/news/breaking/fraudsters-target-citibank/2006/03/07/1141493649374.html
Citibank issues ATM fraud statement
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=19529
Citibank issues ATM fraud statement
http://www.securityfocus.com/brief/157
Citibank reissues cards after fraudulent withdrawals
http://www.channelregister.co.uk/2006/03/07/citibank/
Citibank Reissues Some Payment Cards After Fraudulent Withdrawals
http://www2.csoonline.com/blog_view.html?CID=18837
Security Bytes: Scope of debit card fraud may be widening
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1172241,00.html
PIN Scandal 'Worst Hack Ever;' Citibank Only The Start
http://www.techweb.com/wire/security/181502468
Idiot Watch Citibank Locks Down ATM Cards
http://www.securitypronews.com/news/securitynews/spn-45-20060306IdiotWatchCitibankLocksDownATMCards.html
Citibank Blocks Some Debit-Card Use Abroad
http://www.firstcoastnews.com/money/news-article.aspx?storyid=53363
FraudWatch - Chip&Pin, a new tenner (USD10)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 12, 2006 12:35 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000673.html
some more from yesterday ... including some discussion on
characteristics of static data and replay attacks
http://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"
part of the issue w/x9.59 ... that originally started going on in the
same time-frame as the original chip&pin ... was that the x9a10
financial standards working group was given the requirement (for
x9.59) to preserve the integrity of the financial infrastructure for
all retail payments (ALL as in ALL ... not just point-of-sale, not
just internet, or not just a specific type).
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
some drift about internet-specific activities (but not POS) in the mid-90s
http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
and previous post on work for POS-specific (but not internet) starting
in the same time-frame
http://www.garlic.com/~lynn/aadsm22.htm#20
a few from today:
Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit Fraud
http://www.digitaltransactions.net/newsstory.cfm?newsid=738
That key-chain credit-card fob is an identity theft risk
http://www.mailtribune.com/archive/2006/0312/biz/stories/02biz.htm
Debit cards offer less security than credit cards (less protection under reg-E)
http://www.newsobserver.com/104/story/416556.html
PIN Scandal "Worst Hack Ever;" Citibank Only The Start
http://news.com.com/News.com+Extra/2001-9373_3-0.html?tag=rsspr.6048737
National ATM Card Breach Affecting Triangle Cardholders
http://www.wral.com/news/7859809/detail.html
Banks Issue New Debit Cards After Security Breach
http://www.nbc17.com/money/7859819/detail.html
Breach Of Security Among Debit Card Companies
http://abclocal.go.com/kgo/story?section=7on_your_side&id=3982441
Thieves Compromise Debit Card PINs
http://www.nbc5i.com/news/7857280/detail.html
New Theft Scam Targets Debit Cards
http://www.wsfa.com/Global/story.asp?S=4615928&nav=0RdE
Credit Card Scams
http://www.khqa.com/news/news_story.aspx?id=3875
Thousands Becoming Victims of ATM Fraud
http://www.ksl.com/?nid=148&sid=173996&comments=true
Debit card hackers in huge ATM theft
http://news.monstersandcritics.com/northamerica/article_1135877.php/Debit_card_hackers_in_huge_ATM_theft
Citibank blocks some debit cards
http://www.kansascity.com/mld/kansascity/business/personal_finance/14059928.htm
Debit-card security addressed
http://www.timesleader.com/mld/timesleader/14073650.htm
Hackers crack PINs, rob foreign banks
http://www.bangkokpost.com/breaking_news/breakingnews.php?id=84143
If You Can't Trust Your Bank, Who Can You Trust?
http://www.informationweek.com/blog/main/archives/2006/03/if_you_cant_tru.html
Something In The Cards Prompts Citigroup To Call Them Quits
http://www.institutionalinvestor.com/default.asp?page=1&SID=618305&ISS=21459&type=8
FraudWatch - Chip&Pin, a new tenner (USD10)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 12, 2006 03:49 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
part of the issue was a lot of the early chip&pin work was oriented
towards card vulnerabilities.
skimming (starting by at least the early 90s) and the yes card are
attacks against the infrastructure and the POS terminals.
there may be the possibility of MITM-attacks against dynamic
data authentication of the chip ... i.e. separate from the chip
performing transaction ... something that was looked at in X9.59 work
(in the same time frame as the original chip&pin work) and
required authentication of the transactions ... as opposed to
authentication separate from the transaction. part of this is
understanding broader landscape of threat models ... misc. on
MITM-attacks ... but also some discussion of threat
modeling
http://www.garlic.com/~lynn/subintegrity.html#mitm
however a possible vulnerability (in POS terminal attack) is that
since both static data and dynamic data are part of the
authentication specification ... even if all new cards deployed are
"dynamic" ... terminals may still continue to have support for static
data specification. in such a scenario, it might be possible for a
skimming attack to still acquire sufficient (static data) information
to turn around and build an acceptable counterfeit yes card (where
it then convinces a terminal that it is a valid, older static data
chip).
earlier yes card reference
http://www.garlic.com/~lynn/aadsm22.htm#20
and the more detailed discussion of yes card
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
part of the above is the mention about it staying around forever (or
at least as long as any POS terminals continue to have chip&pin
static data specification support).
NPR : E-Mail Encryption Rare in Everyday Use
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use
Date: Tue, 14 Mar 2006 09:20:46 -0700
To: cryptography@xxxxxxxx
Victor Duchovni wrote:
Of course new domains are less than $4 each in bulk... How will you
lock out throw-away domains? The black-list problem for email is not
solved. The good lists are nowhere near 100% effective. Is the
equivalent of port 25 blocking tractable for Jabber? Is there a
difference between the user-to-server port/protocol and the
server-to-server port/protocol in Jabber?
we were on a business trip and staying in Scottsdale ... not very long
after the green card incident. one night we walked over to a Mexican
restaurant in old town. during the dinner, three people came in and
were seated behind us, a couple and a man that was sat directly behind
me.
the man spent the evening explaining to the couple how he could spam
the world on behalf of their e-commerce webserver ... and also how
they should configure their webserver (no demons other than webserver,
especially no sendmail since some number of the millions of people he
would spam might complain by attempting to send email to their
webserver host name).
he explained that his spamming process was to use some userid to send
out enormous amount of commercial spams (usenet &/or email). At
some point, the ISP would eventually get sufficient complaints and
shutdown his userid. however, he had scores of userids (at different
ISPs all over the country) already pre-setup (this was back in the days
when it was still common to get shell accounts) with spamming software
already preloaded and configured. He could immediately switch to some
other userid with no interruption to his spamming activity ... and
periodically he would establish new userids and preload them with his
spamming software.
minor green card historical reference:
http://en.wikipedia.org/wiki/Green_Card_spam
FraudWatch - Chip&Pin, a new tenner (USD10)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 16, 2006 10:29 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
Confusion reigns over identity of merchants who sparked fraud
http://www.computerweekly.com/Articles/2006/03/15/214826/Confusionreignsoveridentityofmerchantswhosparkedfraud.htm
related old standby post, security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61
and more recent thread
http://www.garlic.com/~lynn/2006e.html#26
Up To 600,000 PIN-Debit Cards Affected In Hack
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1142513626622215212&block=
Your secret PIN may not be so secret
http://news.com.com/Your+secret+PIN+may+not+be+so+secret/2100-1029_3-6050259.html?tag=nefd.lede
Say Hi to the mouse click capturing Trojan (some number of companies have been promoting mouse clicks as countermeasure to pin-capture keyloggers)
http://www.theregister.com/2006/03/16/mouse_click_capturing_trojan/
NACHA Starts Drive to Sign up Participants for Web-Payment Pilot
http://www.digitaltransactions.net/newsstory.cfm?newsid=882
Nacha to pilot online authentication concept
http://www.finextra.com/fullstory.asp?id=15056
after having done aads pilot in 2000
http://www.garlic.com/~lynn/x959.html#aads
http://www.garlic.com/~lynn/x959.html#aads
Poor authentication increases risk of identity fraud
http://www.whatpc.co.uk/vnunet/news/2152120/poor-authentication-increase
Hackers cash in on financial sector attacks
http://www.infomaticsonline.co.uk/vnunet/news/2152006/financial-sector-top-target
Ignoring data breaches means ignoring risk management
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1173214,00.html
>
FraudWatch - Chip&Pin, a new tenner (USD10)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 17, 2006 01:42 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
and if you haven't gotten tired of the current rash of fraud related
news .... here is a few more. also a related post from sci.crypt
http://www.garlic.com/~lynn/2006e.html#30 Debit Cards HACKED now
....
Huge Hack Threatens to Cool off Torrid Growth of PIN Debit Payments
http://www.digitaltransactions.net/newsstory.cfm?newsid=883
Identity Theft Expert Says the Theft of Customers' PIN Numbers from a Major Bank Shows High-Tech Fraud Knows No Bounds
http://www.expertclick.com/NewsReleaseWire/default.cfm?Action=ReleaseDetail&ID=12021
Skimming scares off cash machine users
http://www.silicon.com/financialservices/0,3800010322,39157323,00.htm
Banks do battle with debit-card fraud
http://news.zdnet.com/2100-1009_22-6050777.html
Banks take on debit-card theft
http://news.com.com/2009-1029_3-6050794.html?part=rss&tag=6050794&subj=news
Banks do battle with debit-card fraud
http://news.com.com/2100-1029_3-6050777.html?part=rss&tag=6050777&subj=news
Banks told to adopt stronger authentication
http://www.silicon.com/financialservices/0,3800010322,39157367,00.htm
Your secret PIN may not be so secret
http://news.com.com/Your+secret+PIN+may+not+be+so+secret/2100-1029_3-6050259.html?tag=nefd.top
US payment association to test bank-verified online payments
http://www.cbronline.com/article_news.asp?guid=EC14F55D-7CA3-4CD2-BCA0-CCCE4CD73E6D
House Slated to Pass Data Breach Bill
http://www.securitypronews.com/insiderreports/insider/spn-49-20060316HouseSlatedtoPassDataBreachBill.html
The intersection of Sarbanes-Oxley and insider threats
http://www.computerworld.com/networkingtopics/networking/story/0,10801,109527,00.html
Phishing scammers and data thieves prey on UK companies
http://www.zone-h.org/en/news/read/id=205999/
Meccano Trojans coming to a desktop near you
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 25, 2006 11:38 AM
Subject: Meccano Trojans coming to a desktop near you
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000680.html
The nodes (data at rest) have always been the most at risk. part of
this is that data-at-rest tends to have much larger collection of
aggregated data tending to result in much higher return for the crooks
effort. Furthermore ... long before the internet and continuing right
thru the internet period ... the majority of fraud has always involved
insiders ... again primarily an end-node related issue ... not
data-in-transit issue.
at best, most PKI efforts for data-in-transit, was to not result in
any incremental risk with the introduction of the internet ... as
opposed to really addressing any of the primary threats and
vulnerabilities. however, internet not also provided some incremental
threat against data-in-transit ... but the internet also allowed for
some additional threats/attacks against end-nodes. however, the
various possible internet threats against end-nodes ... may represent
as much an obfuscation of identifying the actual compromise
(insiders), as any real threat, in itself.
However, some number of the end-node infrastructures originally
evolved in a disconnected, non-threat environment ... and as a result
did not have inherent designed-in countermeasures for operating in a
high threat/advisary (internet) environment.
somewhat related discussion
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
Meccano Trojans coming to a desktop near you
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 26, 2006 09:54 AM
Subject: Meccano Trojans coming to a desktop near you
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000680.html
http://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to a desktop near you
There was a online banking conference circa 1995 where the banks
talked about moving to the internet. pre-internet, a bank supporting
online banking ... a typical bank had their own "bank" of (dial-in)
modems and claimed to require 50-60 different versions of software for
different kinds of PCs with different software versions and modem
hardware (along with a well-staffed online banking trouble call
center).
the move to internet banking ... eliminated almost all of their
trouble calls, all their own software development and support
operation and the big call center ... effectively moving that to an
ISP. The ISP amortized the call-in connection across all the stuff
that user might do online and the internet-paradigm standardized the
end-user connectivity software with a paradigm that used the same
software across all online operations. this represented something like
95percent plus reduction in costs to a financial institution for
supporting online operations.
there were some bank factions that had vested interests in preserving
the roll-your-own, dedicated operational paradigm, but the
internet-based operation cost savings were enormous (which was at
least partially because of standardizing and amortizing online
operational costs across everything that an end-user did online)
A big issue with many of the consumer end-nodes has been many of the
underlying platforms originally evolved in a non-hostile environment
with no built-in defensives. Furthermore a large body of
applications (like games) evolved where it was common to take-over
(and compromise) the whole system as part of normal operation.
As a result, some of these platforms now have quite diametricly
opposing requirements ... attempting to apply a defensive layer as an
after thot (i've frequently used the analogy of auto aftermarket
seatbelts as a safety measure from the 60s) to deal with potentially
extremely hostile internet operation while still preserving the
ability for various applications to compromise the system (as part of
normal operation). The 60s aftermarket seatbelts was before the
complete make-over to having some amount of fundamental built-in product
safety.
Meccano Trojans coming to a desktop near you
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 26, 2006 07:09 PM
Subject: Meccano Trojans coming to a desktop near you
MailingList: Financial Cryptography
ref:
http://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#28 Meccano Trojans coming to a desktop near you
part of this going back to at least the early 90s is that crooks would
physically install compromises on end nodes (atm machines,
pos/point-of-sale terminals) to skim/collect information on possibly
tens of thousands of accounts.
this internet scenario involves installing a trojan on a end-node
... possibly getting only a couple accounts per node ... however, the
trojan can be done electronically ... w/o having to physically visit
each node. basically the same skim/harvest static information
vulnerabilities has just been extended to a much larger number of
end-node collection points.
previously mentioned was that skimming threat came into existance at
least in the early 70s with the introduction of magstripe cards and
electronic transactions.
however, one of the earliest magstripe vulnerabilities is somebody
using the algorithm that checks for correctly formed account number
... to generate an account number and create a counterfeit magstripe
with that account number. an early countermeasure for this threat was
cvv genre ... basically a hash of the magstripe that is encrypted with
the bank's secret key. the first part of each account number has the
bank BIN ... which is used for indexing a table for electronically
routing the transaction. The same network table can have the bank
secret key ... so that the CVV value from magtripe can be validated
(an early version of digital signature ... but using secret key
instead of private/public key).
While the cvv process was a countermeasure to algorithmic
generated account numbers and counterfeit magstripes ... it was
subject to skimming vulnerabilities ... i.e. just copy/skim a valid
magstripe and reproduce the magstripe information on a counterfeit
card ... basically a form of replay attack.
the yes card compromise mentioned recently
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
was basically a variation on cvv scenario. the magstripe information
was incorporated into a digital certificate ... with the certification
authority's digital signature. the chip would present the digital
certificate as evidence of being a valid chip. the pos terminal would
validate the (certification authority's) digital signature on the
digital certificate. proving a valid digital signature on a digital
certificate was equivalent to proving a valid chip.
Basically, this generation of chip cards could be skimmed using the
same technology that skimmed magstripes. Validating the digital
signature on the digital certificate was equivalent to validating the
cvv on the magstripe ... in both cases, that validation was treated as
being equivalent proving a valid card (the process for the digital
signature was more complex than any cvv ... but any difficulty making
an electronic copy was essentially identical)
The yes card label came because the POS terminals were
programed that once the terminal validated the digital certificate,
they would accept the chip's statements/directions. The (