Crypto to defend chip IP: snake oil or good idea?
Anne & Lynn Wheeler
lynn at garlic.com
Fri Jul 28 17:52:55 EDT 2006
Thor Lancelot Simon wrote:
> I don't get it. How is there "no increase in vulnerability and threat"
> if a manufacturer of counterfeit / copy chips can simply read the already
> generated private key out of a legitimate chip (because it's not protected
> by a tamperproof module, and the "significant post-fab security handling"
> has been eliminated) and make as many chips with that private key as he
> may care to?
>
> Why should I believe it's any harder to steal the private key than to
> steal a "static serial number"?
so maybe we can look at another kind of static serial number
vulnerability ... besides it will be nominally directly accessable by
general programming and/or transmitted (neither of which would require
capturing with physical intrusive methods).
so for more drift ... given another example of issues with static
data authentication operations is that static serial numbers are
normally considered particularly secret ... and partially as a result
... they tend to have a fairly regular pattern ... frequently even
sequential. there is high probability that having captured a single
static serial number ... you could possibly correctly guess another
million or so static serial numbers w/o a lot of additional effort. This
enables the possibly trivial initial effort to capture the first serial
number to be further amortized over an additional million static serial
numbers ... in effect, in the same effort it has taken to steal a single
static serial number ... a million static serial numbers have
effectively been stolen.
So even if you have a scenario where the effort to steal a single static
serial number is exactly the same as the effort to steal a private key
(because the chips containing them will never divulge and/or export
either ... which is actually a false assumption, but just for argument
sake assume it to be true) ... then we can still claim that when the
effort has been made to steal a single static serial number ... that
effort could then be amortized over a million static serial numbers ...
while you are still stuck with only a single private key. the equation
then is whether "identical effort" divided by one is the same as
"identical effort" divided by a million.
so we could look at it from an additional analogy
http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP:
snake oil or good idea?
and yet again another anlogy/example similar to static serial numbers
tends to be account numbers. one of the static account number
vulnerabilities in the 60s were their regular structure. attackers would
use the regular structure nature of account numbers to conjure up bogus
account numbers from which counterfeit magstripe payment cards were
created. this would frequently be succesful for performing fraudulent
transactions.
eventually the payment card industry came up with a sort of secure hash
that was written to magstripe along with the account number. basically
it was a bank/bin "secret" mashed with the account number. the
association network collected a table of all the bank/bin "secrets" and
could check the secure hash on an account transaction against the
computed value for the account (for instance, if they were going to be
doing standin authorization).
you then started to see bogus reading of the magstripe (static data) by
attackers ... who then would use the recorded information to create a
counterfeit replica.
in the mid-90s, there was chip&pin effort as countermeasure to the bogus
reading of magstripes. there was nothing that could be swiped and read
... so it prevented attackers from creating counterfeit cards from bogus
reads.
the only problem was that sometime in the 80s, you started to also see
attackers recording valid transactions ... they didn't actually need
physical access to the card ... they just needed to be able to record
valid transactions ... and since it was static data ... it could be
readily used for replay attacks using counterfeit magstripe cards.
the chip&pin deployments in the late 90s thru recently would have the
chip present a digital certificate as its authentication. It didn't do
any actual public key operations ... it just presented the certificate.
This was called static data authentication. The problem was that the
technology used for skimming/recording valid (magstripe) transactions
frequently worked equally well recording static data chip&pin
transactions (the attackers didn't require any physical access ... they
just skimmed/recorded valid transactions, in fact they could record tens
of thousands of transactions enabling them to build tens of thousands of
counterfeit cards).
Now since it was purely static data authentication, the attackers found
that they could take a counterfeit chip and install the skimmed/recorded
certificate ... and the chip would now pass as valid. In the late 90s,
this got the label "yes cards" ... old "yes card" reference:
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
the reason for the "yes card" label was that the "chip&pin" effort, in
addition to convert from less secure magstripe to a more secure chip ...
also added requirement that the person enter their pin. the terminal
would pass the pin to (an authenticated) chip and what for the chip to
answer yes or no as to whether the pin was correct. Of course, the
counterfeit chips were programmed to always answer "yes" regardless of
what was passed.
The other was since the chip was so much more secure than the magstripe
... and also more expensive ... infrastructure costs could be saved by
offering to do offline (rather than online) transactions. after the chip
had been authenticated and indicated the correct pin was entered ... the
terminal could then asked the chip if it should do an offline
transaction (rather than online) ... and then because it wasn't checking
with the account ... it also had to ask the chip if the transaction was
within the account credit limit. Of course a counterfeit "yes card" was
also programmed to always answer "yes" to these questions.
as an aside, it should be noted that none of this was an actual attack
on the chip ... it was an attack on the terminal and the static data
authentication paradigm.
as an aside this same time-frame the x9a10 financial standard working
group had been given the requirement to presenve the integrity of the
financial infrastructure for all retail payments. the result was the
x9.59 financial standard for all retail payments
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
previous posts on this subject:
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#53 Case Study: Thunderbird's
brittle security as proof of Iang's 3rd Hypothesis in secure design:
there is only one mode, and it's secure
http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP:
snake oil or good idea?
and just for the fun of it, past posts discussin the "yes card"
vulnerabilities:
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/aadsm22.htm#20 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a
desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a
desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses
are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo,
Elliptics, eBay + fraud, naïve use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera -
(Central) banks don't (want to) know, MS prefers Brand X, airlines
selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were
replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means
Pressed Flowers
http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN
Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN
Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To
DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all
go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle
the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all
go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all
go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all
go naked
http://www.garlic.com/~lynn/aadsm24.htm#21 Use of TPM chip for RNG?
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all
go naked
http://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK
Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#29 DDA cards may address the UK
Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK
Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK
Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK
Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK
Chip&Pin woes
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"
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail
message?
http://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites -
change or not?
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list