[18382] in cryptography@c2.net mail archive
Re: Another entry in the internet security hall of shame....
daemon@ATHENA.MIT.EDU (Alaric Dailey)
Wed Sep 7 15:07:26 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Wed, 07 Sep 2005 12:34:11 -0500
From: Alaric Dailey <alaricd@pengdows.com>
To: cryptography@metzdowd.com
Cc: anti-fraud@lists.cacert.org
In-Reply-To: <431F1A04.6080806@garlic.com>
This is a cryptographically signed message in MIME format.
--------------ms000705040203030402070107
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Thus ATMs and the weak 2 factor authentication system they use are
untrustworthy, I knew that already, but as I said, its better than not
having the multifactor authentication. The fact that many cards may be
used as credit card and you thus bypass the second factor, is a HUMAN
failing, the entity accepting the cards are supposed to check the
signature, against a photo id, ESPECIALLY if the card says "See ID".
But this overabundance of text doesn't solve my problems with the
assertion that PSKs are somehow more secure than Public/Private key
encryption with a trusted third party as verifier, and specifically the
X.509 Certificate Authority System that is the backbone for SSL.
No one is touching on the key issues
sharing of keys securely and how to validate that they haven't been
comprimised.
how a user is supposed to keep track of the secure keys (kind of a side
point)
how the validation of identity of these systems would work
Peter brought up ATMs and I wasn't going to go out on a limb and say
they aren't trustworthy before, but the truth is, they aren't
trustworthy. That being said, its a completely beside the point.
Unless the issues I pointed out are addressed , PSK is a much WORSE
solution than trusting a third party for verification of the other
entities identity. Especially since you profess that certs are
"redundant and superfluous standin for the real information", how I am
to verify that a given website in Timbucktoo, is owned and operated be
the entity making the claim without going there myself, with SSL we have
SOME assurance that someone verified it.
Its no different than trusting that the people at the DMV did their jobs
when a drivers license was issued, but even drivers licenses aren't
acceptable authoritative proof that someone is who they profess to be.
Here in Nebraska we have one of the most difficult drivers licenses to
forge, so what did the criminals do? they stole the machines, so they
could make perfect forgeries. Trust must lie somewhere, if you have a
structure that gives some assurance of that the entities are who they
say they are, that is a world better than lacking those arrurances.
So, my point is very simple, how am I to verify that a website, that I
have no control over, that has the proper PSK is who they say they are?
I have seen no answers, and I still see the same flaw, with ATMs
websites or anything else, a shared key isn't a secret, and if you are
professing it is, how are you to know it hasn't been comprimised?
Anne & Lynn Wheeler wrote:
>Alaric Dailey wrote:
> > ATMs would be infeasible if they were not a 2 factor authentication
>
>
>>system, and every day we see more cracks in the way that system is
>>implemented. Starting with the way the PSKs are shared.
>>
>>http://news.bbc.co.uk/1/hi/technology/4183330.stm
>>
>>
>
>ATMs use "something you have" authentication ... a card with a magstripe
>that is sent out. There is a 2nd factor, PIN, that is also distributed
>... as a countermeasure to lost/stolen cards.
>
>note that both credit cards and many debit cards can be used in non-PIN,
>signature mode (i.e. if the card is lost/stolen, crook may still be able
>to use it w/o PIN).
>
>multi-factor authentication presumes that the different factors are
>subject to different kinds of vulnerabilities and exploits.
>
>PINs are a form of shared-secrets ... security requirements typically
>mean that there is a unique shared-secret for every environment. the
>result is vast proliferation of PINs and passwords leading to people
>writting down their pins & passwords (there was some study that claimed
>30percent of atm cards have pins written on them). As a result,
>multi-factor infrastructure is undermined because of shared-secret based
>environments has led to scores of shared-secrets that people are
>required to keep track of.
>http://www.garlic.com/~lynn/subpubkey.html#secrets
>
>the short-coming of shared-secret environment, is that a shared-secret
>can be used for both origination as well as verification (the same value
> used for authentication can also be used for impersonation), which has
>led to requirement that there are large number of unique shared-secrets,
> which has led to the huge proliferation in the number of shared-secrets
>... which has also led to underminning principle of multi-factor
>authentication ... having unique failure modes .... sorry for that ... I
>spent some large amount of time producing high availability systems ...
>where security exploit/vulnerabilities were just another kind of system
>failure.
>http://www.garlic.com/~lynn/subtopic.html#hacmp
>
>it isn't so much that the key distribution/sharing mechanism is flawed
>... it is that there are flaws in shared-secret based infrastructures
>(including swamping nominal human factors with an impossible number of
>different things to memorize).
>
>The other short-coming in current ATM environment is skimming that can
>go on at the POS or ATM terminal ... where the attackers can record the
>card and pin information. This results in both 1) common vulnerability
>for two factor authentication ... defeating purpose of having
>multi-factor authentication and 2) that existing technology is quite
>vulnerable to replay attacks (aka creating copy of magstripe in
>counterfeit card and being able to reproduce the pin).
>
>So fundamental public key operation can address a number of these
>short-comings w/o resorting to PKI infrastructure and/or changing the
>key and card distribution operation.
>
>1) upgrade magstripe to hardware token that does digital signature
>authentication. the digital signature is unique each time and is
>therefor resistant to existing replay vulnerability, threats and attacks
>
>2) since public key is not a shared-secret based infrastructure ... it
>is practical to record the same public key in multiple different
>environments, in theory transitioning to a person-centric environment
>(from the existing institutional-centric environment). this also is more
>resistant to data breaches ... since any exposure of the recorded public
>key can't be used for impersonation.
>
>3) there is still the issue of using a PIN as countermeasure to
>lost/stolen token ... which is a significantly lower threat compared to
>crooks being able to harvest tens of thousands or millions of pieces of
>information for purposes of account fraud (skimming recording devices at
>ATM & POS terminals or data breaches).
>
>4) with hardware token, the PIN can be used directly with the token for
>token operation ... as opposed to be transmitted and recorded in the
>infrastructure. That eliminates the PIN as a shared-secret. In theory a
>person-centric environment can use the same PIN/token with multitude of
>different infrastructures and/or use the same PIN with multitude of
>different tokens. This last becomes a trade-off between remembering lots
>of PINs (and threat of having them written down) vis-a-vis compromise of
>single PIN can expose several tokens. However, in person-centric
>environment, it is possible to leave such a threat trade-off decision to
>the individual.
>
>The issue of PKI, certificatin authorities, and digital certificates
>were that the original digital certificate design point was for first
>time communication between strangers where the relying party also had
>not timely, direct (possibly online) access to a trusted party. The
>digital certificates filled this trust void in a manner siumilar to
>letters of credit from the sailing ship days.
>
>In an environment where relying parties have long-standing and extensive
>relationship management operations keeping track of large number of bits
>of information ... it is trivial to show that digital certificates are
>redundant and superfluous.
>
>Furthermore, even in the first time communication between strangers ...
>where the relying party has no prior interaction with the subject ...
>digital certificates may still be redundant and superfluous standin for
>the real information if the relying party is able to directly contact
>some authoritative agency responsible for the information (aka real-time
>communication obtaining the real current information in lieu of a
>redundant and superfluous, stale, staic digital certificate).
>
>misc. past person-centric related postings:
>http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst
>case, or average case? (TCPA)
>http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
>http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
>http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so
>dumb???
>http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times
>- open Identity systems
>http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at
>MasterCard processor
>http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and
>authentication
>http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
>http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
>http://www.garlic.com/~lynn/2005m.html#37 public key authentication
>http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
>
>
>
--------------ms000705040203030402070107
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKXzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8wggOKMIIC86ADAgECAgMPYJswDQYJKoZIhvcNAQEE
BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1
MDgyODAwNDMzOFoXDTA2MDgyODAwNDMzOFowgakxDzANBgNVBAQTBkRhaWxleTEPMA0GA1UE
KhMGQWxhcmljMRYwFAYDVQQDEw1BbGFyaWMgRGFpbGV5MSMwIQYJKoZIhvcNAQkBFhRhbGFy
aWNkQHBlbmdkb3dzLmNvbTEnMCUGCSqGSIb3DQEJARYYYWxhcmljZGFpbGV5QGhvdG1haWwu
Y29tMR8wHQYJKoZIhvcNAQkBFhBieXRld3VsZkBhaW0uY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAsndiAxzl3D2f+nOTQcPlwWoTD1hFN58Boc3BeiW/0eV2FwwsC0c6
37enTowaLbGOYU5JOGU6uYi/eYUeY7Ge3uN18ShOhRUsTWDQ3Y8yclz68kTyVctByWvYxECB
2Bm6QTI166T8y1y2N3+sfpecYJSpdDVq6cL82znGJyYVGVkInhahfj2QSF09LL2hDoUpVOdG
Qu2gRMye7Uy5fZ012bzqbOJAAwzM+am5BxEeXD8HamN9tZymCXWEGmZBdcrpk9XVDcnDHYfe
639ApqU+Dbi6uyYAtc1QhFiaeWMxCwTBSumWQsw3Sgfm+xxuKTcu41yQnrtQTMT2tUJqRKJ7
+QIDAQABo4GBMH8wDwYDVR0PAQH/BAUDAwf5gDARBglghkgBhvhCAQEEBAMCBaAwSwYDVR0R
BEQwQoEUYWxhcmljZEBwZW5nZG93cy5jb22BGGFsYXJpY2RhaWxleUBob3RtYWlsLmNvbYEQ
Ynl0ZXd1bGZAYWltLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBADBypc1c
SLRlwln5n2/MksNpJb0CXi71MeqR4RG5JlBYuALF/SxCKwfU4CCw8azboRszQNPLgicQUTT8
EZpDr4f+s9xK2R0V6mKNDtHSMHUdW3w5zlGchhqua+zfHWlJovkMiP3Tpukb53V2aMtGoh6B
QFZEq8nSiHAOhLLNdgT+MIIDijCCAvOgAwIBAgIDD2CbMA0GCSqGSIb3DQEBBAUAMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNTA4MjgwMDQz
MzhaFw0wNjA4MjgwMDQzMzhaMIGpMQ8wDQYDVQQEEwZEYWlsZXkxDzANBgNVBCoTBkFsYXJp
YzEWMBQGA1UEAxMNQWxhcmljIERhaWxleTEjMCEGCSqGSIb3DQEJARYUYWxhcmljZEBwZW5n
ZG93cy5jb20xJzAlBgkqhkiG9w0BCQEWGGFsYXJpY2RhaWxleUBob3RtYWlsLmNvbTEfMB0G
CSqGSIb3DQEJARYQYnl0ZXd1bGZAYWltLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALJ3YgMc5dw9n/pzk0HD5cFqEw9YRTefAaHNwXolv9HldhcMLAtHOt+3p06MGi2x
jmFOSThlOrmIv3mFHmOxnt7jdfEoToUVLE1g0N2PMnJc+vJE8lXLQclr2MRAgdgZukEyNeuk
/Mtctjd/rH6XnGCUqXQ1aunC/Ns5xicmFRlZCJ4WoX49kEhdPSy9oQ6FKVTnRkLtoETMnu1M
uX2dNdm86mziQAMMzPmpuQcRHlw/B2pjfbWcpgl1hBpmQXXK6ZPV1Q3Jwx2H3ut/QKalPg24
ursmALXNUIRYmnljMQsEwUrplkLMN0oH5vscbik3LuNckJ67UEzE9rVCakSie/kCAwEAAaOB
gTB/MA8GA1UdDwEB/wQFAwMH+YAwEQYJYIZIAYb4QgEBBAQDAgWgMEsGA1UdEQREMEKBFGFs
YXJpY2RAcGVuZ2Rvd3MuY29tgRhhbGFyaWNkYWlsZXlAaG90bWFpbC5jb22BEGJ5dGV3dWxm
QGFpbS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAwcqXNXEi0ZcJZ+Z9v
zJLDaSW9Al4u9THqkeERuSZQWLgCxf0sQisH1OAgsPGs26EbM0DTy4InEFE0/BGaQ6+H/rPc
StkdFepijQ7R0jB1HVt8Oc5RnIYarmvs3x1pSaL5DIj906bpG+d1dmjLRqIegUBWRKvJ0ohw
DoSyzXYE/jGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBJc3N1aW5nIENBAgMPYJswCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwOTA3MTczNDExWjAjBgkqhkiG9w0BCQQxFgQUX1C8
3iTzV6WT+6TvCMhutQPuV9YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG
9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYB
BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECAw9gmzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAgMPYJswDQYJKoZIhvcNAQEBBQAEggEAWEFwmdR3P/sQSPFZ
/r4EgwaN18/JMumWlJ0lS0ETXXtlE7tm6DVfWrLkXyOLYglfxb8VV+61a7F+xUx6wLTdRCl+
HP4fuhiZHLGD6TSFwrOSKV0wL5FQObXW895iMP7jrUi0zp5s7ULig5HcCH/4hXvlC5T8WPhV
8TJEyY3qqaaN7h2OIb94e1DR93jGKygnJSGdL2T1Jznqzx1s4u8fVRbXoxqn39ML/UNP9ozU
lUoHQhITUMNJNrafgVMahBuTQWYmNOrHW4LWp6mtENwOxcpcV73/AFcj6pNlbDa3bJXuCFWS
GIzxbRlkw1MSbANClskJm272HewNPgwJFfeIDQAAAAAAAA==
--------------ms000705040203030402070107--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
