Re: Authenticated Public Key Exchange without Digital Certificates?
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 08/09/04
- Next message: BRG: "Re: Encrypted e-mail - what are the laws?"
- Previous message: Mok-Kong Shen: "Re: bootstrapping a secure channel"
- In reply to: Guy Macon: "Authenticated Public Key Exchange without Digital Certificates?"
- Next in thread: Anne & Lynn Wheeler: "Re: Authenticated Public Key Exchange without Digital Certificates?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 09 Aug 2004 08:45:06 -0600
Guy Macon <http://www.guymacon.com> writes:
> I do not share your confidence that "it is practically impossible for
> the private key to ever leave the hardware token." If I have physical
> access to your hardware token, it is very likely that I can extract
> anything that you have inside of it with an Atomic Force Microscope
> - technology that can be found in any CD replication plant. With an
> AFM, I can measure electrostatic, magnetic, capillary, ionic repulsion
> and Van der Waals forces on the surface of the die, scanning back and
> forth and mapping the bits of information.
>
> http://www.cl.cam.ac.uk/~rnc1/descrack/ documents the extracting of a
> 3DES key from an IBM 4758. Do you know of a hardware token that is
> believed to be more secure than an IBM 4758?
>
> To have a secure key, you must have a physically secure location where
> the key is stored. An EAL4-high hardware token won't help you if the
> attacker has physical access.
absolutely ... there is a 5-6 year old thread on this ... all i've got
to do is make the security proporitional to the risk.
so the original story was i wanted to take a $500 (at the time)
milspec part, cost reduce it so that it was both more secure and still
cost effective to deploy on all magstripe cards ... and all i needed
was that it would
a) cost the attacker more to extract the key than they could ever
benefit from having the key
b) take the attacker longer to extract the key than it typically takes
to process a lost/stolen card report and deactivate the registered
public key
some number of chipcards have had infrastructure shared-secret keys
... and therefor extracting the shared-secret key places the whole
infrastructure under attack.
this was targeted at being deployed in the magstripe enhancement
scenario ... i had to make it cheap enuf that it was deployable in
magstripe ... and still be more secure than the original $500
milspec part.
so the issue is that targeting it for an online authentication mode
paradigm ... so we start with the card being lost/stolen and the clock
starts ticking.
first issue is does the attacker get the key extracted before the
public key has been deactivated in the account record ... and
therefor having the private key is of no value.
second issue is even if the attacker marginally wins the race
and is able to possibly execute a single $100 atm financial
transaction before the public key is deactivated ... would the
attacking organization believe it is worthwhile to them.
so in the security world you have threats and countermeasures and is
the possible cost of the attack worth the possible return.
in the financial world you have risks and risk management/mitigation.
risk mitigation is not having any sort of infrastructure shared-secret
... the scope of any compromise is strictly bounded w/o impacting
the whole infrastructure
risk mitigation is having a "something you have" authentication device
that is relatively difficult to compromise/counterfeit.
risk mitigation is online authentication mode infrastructure ...
so that as soon as device is reported lost/stolen ... all transactions
for that specific public key is immediately deactivated.
risk mitigation is online authentication mode infrastructure ...
where it is possible to make the bounds on the possible total value of
active transactions strictly proportional to the assurance level of
the specific device ... where the assurance of any specific device
includes whether it is lost or stolen and/or whether there is
real-time knowledge of emerging technology exploits that will
immediately downgrade the assurance level of subject devices in real
time (possibly change from a $100k credit limit to a $1k credit limit
in real time based on all real time knowledge about assurance level of
the specific devices and/or classes of devices).
one i had to select the different chip pieces that met a broad range
of cost and benefit requirements ... and architect an infrastructure
where there was real-time control over the risk (financial exposure)
proportional to assurance. For instance, having a card lost/stolen
significantly lowered its assurance. Also architect an infrastructure
that eliminated systemic risks .... things like system-wide
infrastructure shared secrets that would put the whole infrastructure
at risk
note that the chip chosen for $300 credit limit accounts ... might not
be the same one chose for $1million credit limit accounts ... or that
the credit limit associated with a specific chip could change in
real-time as circumstances changed.
how many ibm 4758s would you be willing to carry around in your wallet
... especially if you could only do $300 transactions.
the original AADS chip strawman posting from 98
http://www.garlic.com/aadsm2.htm#straw
somebody cross-posted and it ran concurrently on some list in the UK
that involved people actively doing attacks.
actually i have another problem with eal4-high ... the problem is that
most chips with eal5/eal6 evaluations have it done on the bare-bones
infrastructure and the crypto loaded later. the problem if you burn in
the crypto as part of silicon manufactoring and have a chip where the
programming can't be changed, then the evaluation has to be done
against the complete chip ... including the burned in crypto. you may
otherwise have a chip that has been evaluated at eal5 or eal6 ... but
if you have a chip that can't be changed and the crypto has been
burned it as part of silicon manufactoring (i.e. before the wafer has
been sliced and diced) ... then the crypto has to be part of the chip
evaluation. just try finding semi-formal or formal evaluation criteria
for fips186-2, ecdsa in order to do an eal5/eal6 evaluation. there was
a conformance specification that existing momentarily but was almost
immediately withdrawn and they've been promising a replacement any day
now.
also if you look at the published protection profile for smartcards,
almost the while thing is about how do you provide assurance for
loading programming on the chip. if the programming is hardwired and
can't be changed the majority of the protection profile becomes N/A.
random AADS chip strawman pieces:
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in Canada
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm1 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm2 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm4 AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech10 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
http://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#46 Giuliani: ID cards won't curb freedoms
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm16.htm#10 Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)<
http://www.garlic.com/~lynn/aepay10.htm#40 AADS Chip Strawman & aSuretee
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
http://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#46 Giuliani: ID cards won't curb freedoms
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm16.htm#10 Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)<
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay10.htm#40 AADS Chip Strawman & aSuretee
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
- Next message: BRG: "Re: Encrypted e-mail - what are the laws?"
- Previous message: Mok-Kong Shen: "Re: bootstrapping a secure channel"
- In reply to: Guy Macon: "Authenticated Public Key Exchange without Digital Certificates?"
- Next in thread: Anne & Lynn Wheeler: "Re: Authenticated Public Key Exchange without Digital Certificates?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
