Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- Separation of Roles - an example
- RSA Adaptive Authentication
- News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
- News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
- News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
- History and definition of the term 'principal'?
- PGP "master keys"
- PGP "master keys"
- PGP "master keys"
- PGP "master keys"
- PGP "master keys"
- 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
- Shifting the Burden - legal tactics from the contracts world
- Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
- FraudWatch - Chip&Pin, a new tenner (USD10)
- FraudWatch - Chip&Pin, a new tenner (USD10)
- Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
- Petrol firm suspends chip-and-pin
- Petrol firm suspends chip-and-pin
- Reliable Connections Are Not
- Payment systems - the explosion of 1995 is happening in 2006
- Payment systems - the explosion of 1995 is happening in 2006
- Reliable Connections Are Not
- Petrol firm suspends chip-and-pin
- Petrol firm suspends chip-and-pin
- Chip-and-Pin terminals were replaced by "repairworkers"?
- JIBC April 2006 - "Security Revisionism"
- JIBC April 2006 - "Security Revisionism"
- Petrol firm suspends chip-and-pin
- JIBC April 2006 - "Security Revisionism"
- Chip-and-Pin terminals were replaced by "repairworkers"?
- Chip-and-Pin terminals were replaced by "repairworkers"?
- Chip-and-Pin terminals were replaced by "repairworkers"?
- 3 of the big 4 - all doing payment systems
- 3 of the big 4 - all doing payment systems
- 3 of the big 4 - all doing payment systems
- NSA knows who you've called
- Tracking you, tracking me, tracking everyone
- Markets in Imperfect Information - Lemons, Limes and Silver Bullets
- 3 of the big 4 - all doing payment systems
- Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
- Spring is here - that means Pressed Flowers
- ThreatWatch - markets in loss, Visa's take, 419 "chairmen"
- Status of SRP
- Status of opportunistic encryption
- Status of opportunistic encryption
- Status of opportunistic encryption
- Status of SRP
- Status of SRP
- Status of opportunistic encryption
- Status of opportunistic encryption
- Status of SRP
- Status of SRP
- UK Detects Chip-And-PIN Security Flaw
- UK Detects Chip-And-PIN Security Flaw
Separation of Roles - an example
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 16, 2006 12:32 PM
Subject: Separation of Roles - an example
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000699.html
basically, a lot of this is long term standard countermeasures to
insider fraud. i have some recollection of early 80s starting to
really get into threat analysis and countermeasures for insider
exploits.
this somewhat all became obfuscated with the internet and the
attention being paid to outsider exploits .... even thru the whole
internet era, the studies have continued to show that the majority of
fraud is still related to insiders. one might even conjecture the
people behind serious fraud help promote the attention paid to
outsiders as misdirection.
of course the other is that a lot of the internet stuff is somewhat
more likely to make the popular press since the general public has
more awareness of internet as opposed to the long standing backroom
business processes where the majority of financial activity actually
occurs.
as implied, there may be some issue with internet stuff more likely to
involve people who have little or no knowledge and exerpience with
real business issues and history of the serious threats,
vulnerabilities, and exploits.
recent article:
Organization Seen Ignoring Main Culprit in Information Security breaches
http://www.sdcexec.com/article_arch.asp?article_id=8512
references to a few previous articles and/or studies
https://www.garlic.com/~lynn/aadsm12.htm#44 Identity Theft More Often an Inside Job
https://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job
https://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
of course, the above articles relate to (insider) breaches where the
information may be turned around and used for identity and/or account
theft. it doesn't talk about the other kinds of insider fraud like
embezzlement or inflated purchase orders making payments to some
relative.
so for some additional drift, a posting mentioning financial controls,
payment protocols (and digital certificates)
https://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#36 X.509 and ssh
the above references the trival scenario of corporate checks that had
logo stamped on them that they weren't good for more than a certain
value. what they then found was that the work around was to write a
whole collection of such checks (for just under the limit).
One of the times this came up was in the mid-90s involving some PKI
proponents suggesting that digital certificates could have similar
limit statements in support of using PKI-based (offline) financial
transactions emulating the (offline) check model. At about the same
time, there was an article in the national news about a NYC public
school official writing (business checks with limit) 200 checks for
$5000 each to funnel $1m to a front company as part of embezzelment.
The scenario that business had gone to was online transactions
... frequently implemented with a special business card (form of
credit or debit card) that had backend business rules, not only about
amount of individual purchases, but some implemented business rules
about where the card could be used as well as what kind of purchases
that the card could be used. It also had aggregated rules ... about
max. money that could be spent per period (as countermeasure to
embezzlement doing a large number of smaller individual
transactions). Of course, there was also multi-party oversite of
monthly activity (but it gained not requiring detailed multi-party
oversite/approval of each individual purchase) ... which obviously
didn't happen in this particular example.
https://www.financialcryptography.com/mt/archives/000699.html
What some of the PKI promponents had difficulty coming to grips with
was that the stale, static offline check model was being replaced with
dynamic, realtime, online operation.
The stale, static offline credential, certificate, diploma, license,
letters of credit, letters of introduction paradigm had served the
world for centuries providing "trusted" information to relying parties
(who otherwise didn't have any other means of accessing and/or
validating the information).
The PKI digital certificate is an electronic analog of that stale,
static offline paradigm. Many of the PKI proponents seem to have
trouble coming to grips with modern infrastructures moving to online,
realtime operations and away from the old-fashion stale, static
offline method (in part because online, realtime operation can close a
lot of short-comings and vulnerabilities implicit with offline).
RSA Adaptive Authentication
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 18, 2006 11:42 AM
Subject: RSA Adaptive Authentication
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000700.html
when we were doing x9.59
https://www.garlic.com/~lynn/subpubkey.html#x959
https://www.garlic.com/~lynn/x959.html#x959
and aads
https://www.garlic.com/~lynn/x959.html#aads
starting in mid-90s, we called it parameterised risk management
... sort of extension of some of the transaction fraud scoring
... looking at individual transactions ... amount of the transaction,
where the transaction originated, what kind of merchant the
transaction was coming from, possibly what kind of purchases ... as
well as sequence/aggregation of transactions, patterns, etc. ... types
of stuff that you can do in a online paradigm system (can't do with an
offlinestale, static, redundant and superfluous
certificate paradigm).
this was then coupled with the overall integrity level of the token,
and number of authentication factors involved (potentially requesting
additional authentication factors for higher risk operations).
furthermore given the kind of token to indicate the integrity level
(as opposed to fixed integrity level recorded), the token integrity
level could be updated in real time as circumstances changed and
evolved (a token last month good for a million dollar transaction
might only be good for a five hundred dollar transaction this month
... if some vulnerability in particular tokens had been discovered).
If it was a token that had to be used with terminals (POS terminal,
ATM terminal) ... it could also take into account the integrity
characteristics of the terminal (as well as changes to integrity of
the terminal as technology advances over time) and various other
physical location characteristics of the terminal that might increase
or decrease occurance of risk/fraud.
a trivial example was somewhat the state-of-the-art with biometrics at
the point. biometrics was fuzzy match and the infrastructure chose a
fixed biometric scoring threshold ... above the threshold it would be
accepted, below the threshold it would be rejected (this is somewhat
the source of all the stuff in biometrics for false negatives and
false positives). parameterised risk management just took the
biometric scoring value and included it with the rest of the
calculations. if a particular biometric scoring value was less than
dynamic threshold necessary included with all the other calculations
... transaction might be rejected or another biometric value
requested. the biometric state-of-the-art of the period would have
totally different deployed infrastructure for low-value and high-value
payments. parameterised risk management had the same online,
realtime infrastructure and real-time parameterised risk
management would dynamically adjust the requirements to meet the
overall risks of a particular operation.
"dynamic authentication" is essentially just a small subset of
parameterised risk management.
http://www.rsasecurity.com/node.asp?id=3018
the commonly used and well-known example of fraud scoring from the
period was about a credit card being used for a $1 fuel purchase in LA
(checking to see if lost/stolen card had been deactivated with no risk
to the thief) followed within 20 minutes for the purchase of certain
other kinds of goods.
course i've always claimed that parameterised risk management is just
another application of Boyd for agile and adaptable operation.
misc. past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
misc. references to Boyd from around the web
https://www.garlic.com/~lynn/subboyd.html#boyd2
the other comes out of the dynamic adaptive resource management (aka a
kind of dynamic scoring of everything that went on) that I did as
undergraduate in the 60s. It was picked up and included in products
shipped at the time. In the mid-70s, some of it was dropped in
mainframe operating system transition from 360s to 370s. However, I
was allowed to re-introduce it within a couple years as the Resource
Manager product ... 30th anniversary of the blue letter announcing the
Resource Manager comes up on May 11th.
News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2006 10:54 AM
Subject: News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000691.html
so session authentication is vulnerable to trojans ... somewhat akin
to man-in-the-middle attacks ... where the authentication porition is
distinct from the operations to be performed.
the eu finread terminal
https://www.garlic.com/~lynn/subintegrity.html#finread
is somewhat countermeasure to that. each individual transaction is
authenticated ... the finread terminal contains self-contained,
independent keypad (for PIN something you know authentication),
display (so the value of the transaction you are authenicating is the
value you see), and reader (for the token something you have
authentication). 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor
every transaction requires newly displayed value on the finread value
and re-entry of PIN in response.
the eu finread terminal standard calls for certified terminal
... which may benefit the person buying/owning the terminal. this is
countermeasure to compromises of the environment where the
authentication is taking place.
however, one of the things allowed for in the x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
is that a token can digitally sign a transaction (as something you
have authentication) and the environment that the authentication
takes place in can also digitally sign the transaction. this is a
countermeasure to "copy" &/or counterfeit terminals ... aka the
finread standard calls for terminals to meet a certain anti-fraud
specifications ... but doesn't mandate a mechanism for proving that a
finread certified terminal was actually used for any particular
operation (a counterfeit finread terminal may still trivially contain
a trojan).
a digitally signing token (single factor something you have
authentication) can be certified (to the satisfaction of relying
parties) that it only operates when there has been additional
authentication, aka the token requies correct PIN (something you
know) before operation. The validation of a digital signature then
can be taken as imply both something you have authentication as well
as something you know authentication (i.e. two-factor
authentication).
that normal PC end-point environments have been known to be trivially
vulnerable to viruses and trojans for a long time. a certified eu
finread terminal is countermeasure to such viruses and trojans by
providing a separate secure environment where authentication takes
place (as countermeasure to widespread viruses and trojans in the pc
environment).
however, the eu finread terminal specification didn't mandate any
provisions for proving that such a certified terminal was actually in
use ... as a countermeasure to counterfeit terminals. x9.59 standard
provided provisions for both digital signing by the authentication
token as well as provisions for digital signing by the authentication
environment.
one of the issues in previous comments (in other threads) about yes
card attacks ... was that some authentication environment was
compromised (either evesdropping in the physical area of the
authentication or via compromised or counterfeit terminals). The
result of the evesdropping was then used to create the counterfeit
yes cards which were then used as far away as possible. This
two-step process by the crooks was a countermeasure to rapid
identification and elimination of the compromised authentication
environment (and any associated compromised or counterfeit terminal).
This maximized any non-trivial investment to compromise the
authentication environment (and maximize the fraud
return-on-investment).
another countermeasure has been privately owned PDA or cellphone
devices for use in authenticated transactions (to unfamiliar terminals
that may be compromised or counterfeit) ... assuming they have similar
attack countermeasure properties as found in eu finread terminals. one
of the more recent issues as that as PDAs and cellphones become more
sophisticated, it seems to also be increasing their susceptibility to
viruses and trojans.
misc. past posts related to yes cards
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2006 11:11 AM
Subject: News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000691.html
vis-a-vis security is harder than you think
long series of postings (dating back to ancient history) on the evils
of buffer overflows and that common C language environments are
especially vulnerable to coding mistakes that result in buffer
overflows.
https://www.garlic.com/~lynn/subintegrity.html#overflow
and of course long series of postings regarding SSL (also dating back
to ancient history) ... especially SSL digital certificates ... and
frequently that they have more contributed more to the feeling of
"comfort" (than any actual security)
https://www.garlic.com/~lynn/subpubkey.html#sslcert
News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2006 03:10 PM
Subject: News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
MailingList: Financial Cryptography
oh, for a little drift, some additional, recent comments regarding
attacks on the "authentication environment" ... as opposed to attacks
on the actual authentication ... and countermeasures.
https://www.garlic.com/~lynn/2006h.html#14 Security
History and definition of the term 'principal'?
Refed: **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: History and definition of the term 'principal'?
Date: Wed, 26 Apr 2006 14:31:23 -0600
To: cryptography@xxxxxxxx
Victor Duchovni wrote:
So with Kerberos the word has its narrower "named security entity"
technical meaning. With X.509 one tends to talk of "subjects", "issuers",
"registration authorities", "certification authorities", ... and the word
"principal" is less common.
part of this has been that x.509 has layered certification
authorities, digital certificates and other business processes on top
of any direct interaction between parties. as a result, the focus of
x.509 related descriptions tends to focus on the certification
processes and the acceptance of those certification processes by
relying parties (along with any digital certificate representation
of those certification processes)
credentials, certificates, licenses, diplomas, letters of
credit/introduction and other mechanisms have served the world for
centuries ... providing information to relying parties, where the
relying parties didn't have the information themselves and/or have
other mechanisms for obtaining the information.
digital certificates has been electronic analog of those centuries old
constructs for representation of information for use by relying
parties (where the relying parties have no direct access to the
information and/or other mechanisms for obtaining the information).
in my merged security taxonomy and glossary collected from a variety of
resources
https://www.garlic.com/~lynn/index.html#glosnote
aka:
Security
Terms merged from: AFSEC, AJP, CC1, CC2, CC21 (CC site), CIAO, FCv1,
FFIEC, FJC, FTC, IATF V3 (IATF site), IEEE610, ITSEC, Intel, JTC1/SC27
(SC27 site), KeyAll, MSC, NIST 800-30, 800-33, 800-37, 800-53, 800-61,
800-77, 800-83 FIPS140, NASA, NCSC/TG004, NIAP, NSA Intrusion, CNSSI
4009, online security study, RFC1983, RFC2504, RFC2647, RFC2828, TCSEC,
TDI, TNI, vulnerability testing and misc. Updated 20060202 with terms
from 800-77, 800-83
the only definition for principal comes from sc27:
principal
An entity whose identity can be authenticated. [SC27]
the merged taxonomy and glossaries from X9F (including some x.509
sources), i.e.
X9F
Terms merged from X9F document glossaries: WD15782, X509, X9.8,
X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69. Terms
from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary
(identified by lower case x9 instead of upper-case X9). Original
source documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9,
x9.17, x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42,
x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69 x9.74, x9.76,
x9.78, x9.80, x9.82, and TG-17. (990710)
doesn't include a definition for principal.
PGP "master keys"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Fri, 28 Apr 2006 08:17:46 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Derek Atkins <warlord@xxxxxxxx>, cryptography@xxxxxxxx
Steven M. Bellovin wrote:
Ah -- corporate key escrow. An overt back door for Little Brother,
rather than a covert one for Big Brother....
the key escrow meetings attempted to differentiate between keys used
for authentication and keys used for securing corporate data (I only
went to a couple of the meetings). the case of key escrow as part of
securing corporate data was similar to business processes for backing
up corporate data, disaster recovery, and no single point of
failure. in fact, escrow of authentication keys was equally a
violation of business standards as not having escrow of encryption
keys.
there was cross-over from backup infrastructure and the transition
from all corporate data residing in hardened datacenters to individual
desktops ... where the they were finding critical corporate data being
managed and maintained w/o adequate backup and recovery capabilities.
the point of key escrow as part of infrastructure securing corporate
data ... was that the data belonged to the corporation ... and loss of
keys could be equivalent to losing the data ... and as such, was as
negligent as not backing up critical corporate data and not having a
disaster/recovery plan.
there was some backup related study that claimed half of the
corporations that had a disk failure (where the disk was not being
backed up) containing critical corporate data ... filed for bankruptcy
withing 30 days of the failure. i assumed that "critical" was stuff
like account-billable files ... loosing a month worth of customer
account billing information could create a real dent on the
corporation's cash flow. one incident involved a corporation that lost
something like $50m in monthly billings.
it wasn't suppose to be a back door to anything ... anymore than
having copies of all corporate files on corporate backup tapes
(however, the corporate backup tapes wouldn't be worth a lot if all
the data has been secured with encryption ... and the encryption keys
are lost).
PGP "master keys"
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Fri, 28 Apr 2006 09:42:51 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Derek Atkins <warlord@xxxxxxxx>, cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
note from the corporate side ... is was specifically the escrow of
encryption keys for data at rest ... as part of prudent corporate
asset protection; it was not escrow of authentication keys nor escrow
of encryption keys used for communication.
the internal network was larger than the arpanet/internet from just
about the beginning until possibly around summer of 85. at the time of
the great change-over to internetworking protocol on 1/1/83, the
number of arpanet/internet nodes was approx. 250 (a number that the
internal network had passed in the mid-70s, the internal network
passed 1000 nodes a little later in 83).
https://www.garlic.com/~lynn/subnetwork.html#internalnet
corporate inter-site links had to be encrypted ... which at the time
met link encryptors .. there were claims that the internal network had
over half of all the link encryptors in the world. there wasn't any
corporate escrow issues with link encryptor keys. there were various
problems with gov. agencies ... significant problems especially in
europe getting gov/ptt authorization for corporate link encryptors (on
corporate links, between corporate sites, purely carrying corporate
data) especially when the links crossed country boundaries.
issues did start showing up in the mid-90s in the corporate world ...
there were a large number of former gov. employees starting to show up
in different corporate security-related positions (apparently after
being turfed from the gov). their interests appeared to possibly
reflect what they may have been doing prior to leaving the gov.
misc. past postings (mostly) referencing (internal) link encryptors
https://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm18.htm#50 link-layer encryptors for Ethernet?
https://www.garlic.com/~lynn/aadsm18.htm#51 link-layer encryptors for Ethernet?
https://www.garlic.com/~lynn/2002b.html#56 Computer Naming Conventions
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
https://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003i.html#62 Wireless security
https://www.garlic.com/~lynn/2004g.html#33 network history
https://www.garlic.com/~lynn/2004g.html#34 network history
https://www.garlic.com/~lynn/2004p.html#44 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#51 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#52 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
https://www.garlic.com/~lynn/2005u.html#46 Channel Distances
https://www.garlic.com/~lynn/2005u.html#60 1970s data comms (UK)
https://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006e.html#37 The Pankian Metaphor
PGP "master keys"
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Fri, 28 Apr 2006 09:54:51 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Derek Atkins <warlord@xxxxxxxx>, cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
https://www.garlic.com/~lynn/aadsm23.htm#7 PGP "master keys"
and real-time reference from today ... on backup tapes ... at off-site
location ... that weren't encrypted (and should have been):
Data storage firm apologizes for loss of railroad data tapes
Information on as many as 17,000 workers at risk
http://www.boston.com/business/globe/articles/2006/04/28/data_storage_firm_apologizes_for_loss_of_railroad_data_tapes/
PGP "master keys"
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Sat, 29 Apr 2006 07:23:01 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Derek Atkins <warlord@xxxxxxxx>, cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
issues did start showing up in the mid-90s in the corporate world
... there were a large number of former gov. employees starting to
show up in different corporate security-related positions
(apparently after being turfed from the gov). their interests
appeared to possibly reflect what they may have been doing prior to
leaving the gov.
re:
https://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
https://www.garlic.com/~lynn/aadsm23.htm#7 PGP "master keys"
https://www.garlic.com/~lynn/aadsm23.htm#8 PGP "master keys"
one of the issues is that corporate/commercial world has had much more
orientation towards prevention of wrong doing. govs. have tended to be
much more preoccupied with evidence and prosecution of wrong
doing. the influx of former gov. employees into the corporate world in
the 2nd half of the 90s, tended to shift some of the attention from
activities related to prevention to activities related to evidence and
prosecution (including evesdropping).
for lots of drift ... one of the features of the work on x9.59 from
the mid-90s
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
was its recognition that insiders had always been a major factor in
the majority of financial fraud and security
breaches. furthermore that with various financial functions
overloaded for both authentication and normal day-to-day operations
... that there was no real practical way of eliminating all such
security breaches with that type of information. ... part of
this is my repeated comment on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
the x9.59 approach was to eliminate the function overload so that the
same information that was needed for normal day-to-day operation
didn't also carry with it any authentication feature/attribute. the
result was that data breaches could still occur, but no longer
enabled the financial fraud that it once did ... and therefor
it didn't really represent a serious security breach ... aka
the countermeasure to financial fraud associated with the
data breaches was to recognize that it was impossible to
totally eliminate them, since the information was required extensively
in day-to-day business processes, so to prevent the wrong doing, the
authentication feature/attribute was removed from the associated
information.
PGP "master keys"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Mon, 01 May 2006 11:56:18 -0600
To: leichter_jerrold@xxxxxxxx
CC: smb@xxxxxxxx, warlord@xxxxxxxx, cryptography@xxxxxxxx
leichter_jerrold@xxxxxxxx wrote:
A similar issue occurs in a civilian context, sometimes with fake
employees, other times with fake bills. Often, these get found
because they rely on the person committing the fraud being there
every time a check arrives: It's the check sitting around with no
one speaking for it that raises the alarm. The long-standing policy
has been to *require* people in a position to handle those checks to
take their vacation. (Of course, with direct deposit of salaries,
the form of the fraud, and what one needs to do to detect it, have
changed in detail - but probably not by much.)
multi-party operations were supposedly countermeasure to single
person insider threats. the fraud response was collusion. so by at
least the early 80s you started seeing work on collusion
countermeasures. 25 years later, things have regressed to a
pre-occupation with outsiders, intrusion threats and intrusion
countermeasures; even tho insiders have continued to be the
major source of fraud through the whole period. insiders may even
leverage the pre-occupation with intrusion and outsiders to obfuscate
the source of the exploit.
somewhat related issue with regard to sarbanes-oxley and auditing
assumptions about independent information sources looking for
inconsistencies.
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
and a couple recent articles about current fraud pre-occupation
SSL Trojans: The next Great Bank Heist
http://www.infoworld.com/reports/18SRsslmalware.html
Ripped Off: Identity Theft - A View from the Financial Services
Industry
http://www.mondaq.com/article.asp?article_id=39334&mostpopular=1
other posts in this thread:
https://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
https://www.garlic.com/~lynn/aadsm23.htm#7 PGP "master keys"
https://www.garlic.com/~lynn/aadsm23.htm#8 PGP "master keys"
https://www.garlic.com/~lynn/aadsm23.htm#9 PGP "master keys"
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 3, 2006 10:37 AM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
trsm.mckay on April 18, 2006 06:30 PM wrote:
Lynn: If you configure a system so that a token is required to
perform a digital signature (e.g. contains the private key), and
that a PIN is requested every time the token performs a digital
signature (e.g. unlocks the token for a single transaction) - is
that sufficient to judge the intent of the user to sign the email?
At first glance I would think so, but there is an interesting
philosophical line between specific intent and rote practice.
ref:
https://www.financialcryptography.com/mt/archives/000697.html
https://www.garlic.com/~lynn/subpubkey.html#signature
the issue isn't that the PIN is entered every time for the digital
signature to imply human read, understood, agrees, approves, and/or
authorizes ... the PIN has to be entered in response to a statement
asking if the person agrees.
at POS terminal, the PIN entry and swiping the debit card is taken as
two-factor authentication ... not human signature. the current
pin-debit has the person entering the PIN and swiping the debit card
on every transaction. from 3-factor authentication:
https://www.garlic.com/~lynn/subintegrity.html#3factor
- something you have
- something you know
- something you are
where the PIN entry represents something you know
authentication and swiping the card represents something you
have authentication (the current debit card PIN entry is
equivalent to PIN entry with a digital signing hardware token and the
current card swipe is equivalent to a hardware token doing a digital
signature)
however, the part of the current POS terminal pin-debit transaction
that represents read, understood, agrees, approves, and/or
authorizes is NEITHER the PIN entry NOR card-swipe (the PIN entry
and the card-swipe just represents two factor authentication).
the part of the current POS terminal pin-debit transaction that
represents read, understood, agrees, approves, and/or
authorizes (aka human intention or human signature) is when the
terminal displays the transactions and asks the person to hit the
yes/agree/enter button. Hitting that button is some explicit human
operation that carries with it the sense of intent and having read,
understood, agrees, approves, and/or authorizes.
In the current POS terminal pin-debit tranactions, neither the PIN
entry NOR the card-swipe represents having read, understood,
agrees, approves, and/or authorizes (i.e. doesn't represent human
intention or human signature).
If the current POS terminal were to be redesigned for an X9.59 transaction
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
with a digital signing token that used a PIN ... and the terminal
displayed the transactions and asked for the person to enter the PIN
if they agreed ... then the entry of the PIN would be a demonstration
of intent and having read, understood, agrees, approves, and/or
authorizes.
If that PIN entry (in response to the message asking the person to
enter the PIN as indication of agreement) and the digital signature
was tied to the PIN entry ... then you have a chain of events that
could imply having read, understood, agrees, approves, and/or
authorizes (aka human intention and/or human signature).
The problem is with out that chain of events ... the PIN entry and
digital signature is purely an indication of authentication and is not
tied to any indication of having read, understood, agrees, approves
and/or authorizes (or human intention and/or human signature)
It isn't that the digital signature can be demonstrated as part of PIN
entry. The digital signature and the PIN entry by themselves are still
simple pieces of multi-factor authentication and by themselves don't
rise to the level of human intention or human signature.
It is some human action in response to something ... that rises to the
level of human intention and having read, understood,
agrees, approves, and/or authorizes. The "PIN entry" as a human
action in response to a message asking for "PIN entry" as indication
of agreement then rises to the having read, understood, agrees,
approves, and/or authorizes (human intention, human
signature).
previous posts in this thread:
https://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm22.htm#48 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
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 3, 2006 11:37 AM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
aka, the PIN entry and the digital signature are purely multi-factor
authentication.
re:
https://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/subpubkey.html#signature
however, if a certified environment can tie the digital signature to
the PIN entry ... and the PIN entry to a human response/action asking
for indication of agreement ... then that sequence of certified
operations can be traced back to a specific human response asking for
indication of agreement ... then you have a basis for tieing the
existance of a digital signature back through a sequence of operations
to some human response that can be taken as an indication of having
read, understood, agrees, approves, and/or authorizes
(i.e. human intent, human signature).
the digital signature as an indication of human intent ... has very
little to do with the word signature appearing in the term
digital signature and also in the term human
signature. the "digital signature" is purely an indication of some
operation. if a particular "digital signature" can be shown to be the
final operation in a sequence of certified opeations that originated
with some human response/action in response to something ... then you
can use that sequence of certified operations as an indication of
read, understood, agrees, approves, and/or authorizes
(human intent, human signature).
this is one of the justifications for the x9a10 financial standards
working group to have allowed for an x9.59 transaction to having a
pair of digital signatures.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
the initial digital signature is supposedly from an entity's hardware
token that is part authenticating that entity.
the second digital signature is by the digital signing environment
... say something like a certified finread terminal
https://www.garlic.com/~lynn/subintegrity.html#finread
the second digital signature is authenticating that a certified
digital signing environment was used for the first digital signature
... and that certain certified operations occured as part of the
generation of the first digital signature. again ... the digital
signatures themselves are not indications of human intent or human
signatures.
the first digital signature is to authenticate the human (not directly
indicate human intent)
the second digital signature is to authenticate the digital signing
environment ... and for specific certificate digital signing
environments there may also be certified sequence of operations that
are required to occur that then may be taken as an indication of a
human having read, understood, agrees, approves, and/or authorizes
(human intent, human signature).
it isn't the digital signatures themselves that indicate human intent.
the first digatal signature can be taken as authenticating a specific
hardware token ... implying something you have authentication for a
human. it is also possible that the speicific hardware token is
certified to operate in a specific way (say the entry of the correct
PIN or biometrics) as part of producing the digital signature. In that
case, the first digital signature might be taken to imply both
something you have authentication (the person has the token) and
something you know authentication (the person has entered the correct
PIN).
Then the second digital signature can be taken as authenticating a
specific digital signing environment ... and that digial signing
environment has a certified process that has a specific sequence of
events. For a specific POS terminal environment, the certified
sequence of events is that the terminal displays the transaction
amount and asks the person to enter the (hardware token) PIN if they
agree to the transaction.
It isn't the existance of either digital signature that directly
establishes a human having read, understood, agrees, approves,
and/or authorizes (human intent, human signature). It is
that the digital signatures are taken as authenticating specific
certified operations.
The first digital signature can be taken as implying two-factor
authentication since there is a specific hardware token that is
certified as having a unique private key and that the use of that
private key to generate a digital signature is certified as requiring
the correct PIN.
The second digital signature can be taken as implying a specific
digital signing process because there is a specific POS terminal that
is certified as having a unique private key and that the use of that
private key to generate a digital signature is certified as only
happening after a sequence of other events involving a hardware token
and human actions.
This basically corresponds to the current direction of
non-repudiation. The (stale, static) x.509 digital
certificate non-repudiation bit has pretty much been totally
depreciated. What is now being defined for non-repudiation are
various kinds of "services" which are certified as executing a
specific sequence of processes.
In that sense, the certified terminal operation discussed in this
posting is a service that has a specific certified sequence of
processes. furthermore, the terminal also digitally signs the
operation as authenticating the service/processes associated with the
hardware token digital signature.
again, there appears to have frequently been semantic confusion
with the word signature appearing in both the term digital
signature and the term human signature. the term "digital
signature" is purely a manifestation or representation of a specific
certified sequence of operations.
in order to understand what a "digital signature" might represent
... you then have to understand the exact sequence of operations that
can be certified as occuring leading up to the generation of the
"digital signature"
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 3, 2006 03:20 PM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
so lets look at it from a slightly different perspecitve.
things end with the existance of a digital signature. the actual
digital signature is representative of something you have
authentication. it is the process of getting to the digital signature
that correlates the creation of the digital signature with having
read, understood, agrees, approves, and/or autherizes
(human intent).
your suggestion was creating a certified process that can demonstrate
that the generation of the digital signature was dependent on some
human action (entering a PIN).
however, what was missing was being able to demonstrate any
relationship between the human action entering of the PIN and having
read, understood, agrees, approves, and/or autherizes
(huamn intent).
so you need to show that
- the human response was a result of having read, understood, agrees,
approves, and/or authorizes (human intent)
- the entering of the PIN was a specific a human response
- the generation of the digital signature was the result of entering
the PIN
- the existance of the digital signature was the result of the
generation of the digital signature.
the previous postings describe a second digital signature by a digital
signing environment ... that digital signing environment is certified
as requiring steps 1-4 as part of having the existence of a specific
digital signature in conjunction with some specific item that has been
digitally signed.
ref:
https://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
the other way of looking at it is from a trust path analysis for
assurance and integrity. imagine the existance of a digital signature
is the trunk of a tree. there are possibly millions of root endings
that can lead to having the existance of a digital signature as a
result. I choose the root endings that specifically start with
human intent and then demonstrate a trusted path from the start
at human intent (at some set of root endings) until I arrive at
the existance of a digital signature (at the turnk)
then i work the process from the reverse direction ... can I start
with the existance of a specific digital signature and have proof that
it only traces back to starting with human intent ... or is it
possible I could have arrived at the existance of a specific digital
signature by starting someplace that doesn't involve human
intent at all.
this is somewhat how i came up with the dual-use vulnerability
of using digital signatures for both plain authentication as well as
demonstration of human intent (i.e. read, understood,
agrees, approves, and/or authorizes). I show that you can
establish a trusted path from human intent to digital signature
existance.
I then show that common digital signature authentication mechanisms
will pass some random data to the client for digital signing (as
countermeasure to replay attack on authentication). The
client signs the random data w/o looking at it. I now can demonstrate
getting to the existance of a digital signature that didn't originate
with human intent.
I can also start with some other set of root endings that has a unique
private key in a specific hardware token and that hardware token is
given to a specific individual. I then show a direct path to the same
"digital signature" at the trunk.
Starting with the something you have authentication root
ending, you arrive at the existance of the digital signature
representing something you have authentication. I may also be
able to get to the same digital signature from starting with human
intent and show a directly connected, certified, trusted, sequence
of operations also results in the existance of the same digital
signature. However, w/o one the one set of sequence of events, it is
impossible to assume something you have authentication. W/o the
other sequence of events, it is not reasonable to assume human
intent
So the dual-use attack is can any server pass some valid
transaction or contract in the guise of random data and have it signed
w/o human intent being involved.
So there has been a couple of different suggestions as
countermeasure to digital signature dual-use
vulnerability. One is that you can proove that for every instance
where you have applied a digital signature that didn't involve
human intent, you appended a disclamer to the random data
first, stating this particular digital signature was to not imply
human intent. One problem is prooving a negative is difficult
(showing that you have never generated a digital signature w/o first
including the disclamer).
The other approach is having the digital signing environment also
digitally sign the operation. The first digital signature by some
something you have authentication is some certified mode of
operation (that can be trusted by relying parties). The second digital
signature attests to the certified sequence of operations that results
in the existance of the first digital signature. This is sort of the
certified EU finread terminal with the additional that the terminal
also has to sign the same operation.
As I've commented before, some of this is possibly semantic
confusion where the word signature occurs in totally different
terms: digital signature and human signature.
The other scenario may be akin to the comfort that many people get
from digital certificates.
For centuries, credentials, certificates, diplomas, licenses, letters
of credit, letters of introduction, etc ... have been used to
represent some information and/or processes.
Digital certificates are the electronic equivalent to this physical
objects that have existed for centuries (as representation of
something). My long tirade is that with online connectivity it is no
longer necessary to settle for digital signatures as a substitute
representing something ... you can have direct, real-time access to
the real thing.
A digital signature on something is also a representation of
something. However, a digital signature represents something you
have authentication ... it doesn't represent human intent
(as in read, understood, agrees, approves, and/or
authorizes). This confusion is somewhat similar to peoples'
mistaken perception that the existance of the non-repudiation
bit in digital certificate as representing non-repudiation
(just because some set of words are used in naming something
... doesn't automatically convey any attributes normally associated
with the individual words ... to the named thing).
some past posts mentioning digital signature dual-use vulnerability:
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
https://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#28 solving the wrong problem
https://www.garlic.com/~lynn/aadsm21.htm#10 Clearing sensitive in-memory data in perl
https://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#6 long-term GPG signing key
https://www.garlic.com/~lynn/aadsm22.htm#7 long-term GPG signing key
https://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client certificate for partner access
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
https://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
Shifting the Burden - legal tactics from the contracts world
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 4, 2006 03:22 PM
Subject: Shifting the Burden - legal tactics from the contracts world
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000710.html
http://unenumerated.blogspot.com/2006/05/security-and-burden-of-lawsuit.html
this is sort of my repeated description that the explicit contract is
between the certification authority and the party that is having the
certificate certified (and pays for the certificate).
this has represented an enormous problem all along for the trusted 3rd
party certification authority operations. the foreys during the 90s to
address the problem included trying to get legislation passed
mandating digital certificates from "approved" certification
authorities (codifying the relationship as rule of law ... outside of
the business contract infrastructure).
the federal PKI program took another approach. GSA as representing the
federal government relying party ... signed contracts with each of the
approved certification authorities ... effectively making the approved
certification authorities a kind of agent of the GSA (federal
governemnt relying party) ... and therefor the certificates became a
form of relying-party certificates (i.e. a legal fabrication that the
entity issuing the digital certificates was the same as the entity
relying on the certificates). misc. past posts about
relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
this got around the problem of missing any sort of contractual
relationship between the certificate issuing certification authorities
and the relying party.
There was another effort in the mid-90s which touches both on changing
the burden of proof as well as intent.
Some early digital certificate standard effort got really confused and
defined a non-repudiation bit. This was taken to imply that if a
relying party could produce a (any) digital certificate for a specific
public key that could be used to validate a specific digital signature
... then whatever that digital signature had been applied to ... could
be construed as a human intent (i.e. read, understood, agrees,
approves, and/or authorizes).
The scenario was that there was resistance in the merchant population
to spend the money installing the facilities to support digital
certificate (PKI) based financial transactions. The non-repudiation
proposal was that if a merchant could produce a (any) digital
certificate (for a consumer's public key) containing the
non-repudiation bit then in any disputes involving a related
digitally signed financial transaction, the burden of proof would be
reversed (i.e. burden of proof shifted from the merchant to the
consumer).
So this represented some huge issues.
It eventually came to be generaly realized that having a
non-repudiation bit in a digital certificate carried no meaning
... and the bit definition has since come to be depreciated.
The standard PKI protocols call for appending digital certificates to
digitally signed operations ... but provide for no assurance mechanism
that can prove what digital certificate a consumer actually appended
to any specific transaction.
There would be no incentive for a consumer to actually append a
non-repudiation bit carrying digital certificate to anything
(especially when doing so shifted legal liability to them from the
other party). On the other hand, there would be lot of incentive for a
merchant to discover and be able to produce some consumer digital
certificate with the non-repudiation bit set (even possibly if it
wasn't originally appended).
Part of the confusion goes back to attempts to equate digital
signatures to human signatures (as evidence the definition of a
non-repudiation bit in digital certificate specification). Some of
this could be considered semantic confusion with the word
signature appearing in both the terms digital signature and
human signature.
If you trace back all the steps that a "digital signature" can
represent, it basically comes down to something you have
authentication. There is nothing in any of the operations specified
for dealing with a "digital signature" that can tie a existance of a
"digital signature" to human intent (some human operation tied to
read, understood, agrees, approves, and/or authorizes).
a couple recent posts on the subject:
https://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signature
https://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signature
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signature
I expect that attempting to relate digital signature to human
signatures and human intent (having read, understood,
agrees, approves, and/or authorizes) will eventually go through
some similar evoluation that happened to the non-repudiation
concept. Rather than the existance of a static bit created at some
point in the distant past, the most current non-repudiation
thinking involves a whole bunch of (non-repudiation) services
that *certify* specific sequence events occured as part of some
operation (and it was these sequence of events as part of each
operation that were necessary for creating the basis of any sort of
non-repudiation).
A similar evoluation in the concept of human intent will be
services that can certify that specific sequence of events occured as
part of doing an operation (say digitally signing a transaction) that
are the basis for establishing human intent (read,
understood, agrees, approves, and/or authorizes). It isn't the
existance of the digital signature that represents any sort of
human intent (i.e. the actual digital signature just
represents something you have authentication). It is the
certifying of these other events, performed in conjunction with the
digital signature, that is necessary for establishing the basis of any
sort of human intent ... and therefor can be treated as
human signature (read, understood, agrees, approves, and/or
authorizes).
misc. past posts mentioning having worked on some of the word smithing
of the cal. state electronic signature legislation and later the
federal electronic signature legislation.
https://www.garlic.com/~lynn/subpubkey.html#signature
Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 5, 2006 03:52 PM
Subject: Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000709.html
E-commerce in crisis: When SSL isn't safe
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature
the PC end-point vulnerability has been long recognized ... that is
part of the early motivation for the EU FINREAD terminal standard.
https://www.garlic.com/~lynn/subintegrity.html#finread
FINREAD moved authentication out of vulnerable PCs into a trusted
authentication environment as well as providing mechanism for
supporting transaction-based authentication (each
transaction/operation is explicitly authentication) as opposed to just
simple session authentication (with possibly encryption wrapper for
security).
The recent discussion is that if you have a separate trusted
authentication environment for authentication (based on digital
signature authentication) then there are some additional benefit to
relying parties to also have the trusted authentication environment
also digitally signing the operation (so the relying party has some
proof that a trusted authentication environment was in use as opposed
to some compromised/counterfeit authentication environment).
https://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signatures
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures
with respect about to earlier comment about having a token that
requires a digital signing hardware token to have correct (human) PIN
entry .... would allow a relying party to be able to associate a
specific digital signature with some human operation (PIN entry), if
the relying party had some way of knowing that the hardware token
being used, in facted, required PIN entry.
Issues addressed by the EU finread terminal standard was to eliminate
PC virus/trojan from logging the PIN value and then replaying the PIN
values to the hardware token (w/o the users knowledge). The EU finread
terminal standard provided from a countermeasure to the PC
virus/trojan replaying PIN entries. However, the EU finread terminal
standard didn't actually require the terminal to also digitally sign
the transaction (providing an indication to the relying party that an
finread terminal was actually being used ... as opposed to some
counterfeit environment). For financial transaction, the finread
terminal extracted the important parts of the data to be signed
and displayed it along with the request for PIN-entry (as
countermeasure to virus/trojan displaying a value different
that what is in the actuall transaction)
There is an issue with the relying party knowing the operational
characteristics of the hardware token being used for a digital
signature (w/o which the relying party has no mechanism to know
whether PIN-entry was even required ... or even if a hardware token is
being used). The relying party having knowledge of the hardware token
operational characteristics allows for some evaluation of whether it
was actual simple one-factor authentication (something you have)
... or if possibly additional authentication factors were involved
(multi-factor authentication).
There is also an issue with the relying party having knowledge of the
operational characteristics of any kind of terminal (or other digital
signing environment) that also digitally signs the operation. This
provides the relying party with basis for doing further trust
evaluation (like whether there was possibility that virus/trojan
entered the PIN).
Finally with respect to comment about associating PIN-entry with
indication of any human intent (read, understood, approves,
agrees, and/or authorizes)
https://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures
The relying party having knowledge of the hardware token may have some
basis for assuming that the digital signature implies that (the
correct) PIN was entered. Having the 2nd digital signature from the
terminal provides some basis for assuming that the PIN entry actually
involved human interaction. That ties the token's digital signature to
some human interaction. However, there is still no tie between the
human interaction and read, understood, approves, aggrees, and/or
authorizes.
However, if the relying party has knowledge of the terminal
environment (that also digitally signs the operation), then there may
be some basis for assuming that the terminal had displayed a message
requesting the person to enter their PIN if they agreed with the
operation (and critical pieces of the transaction is also displayed),
and that the PIN was entered after the message was displayed. There is
now some basis for the relying party to assume that the human
interaction (PIN entry) was in response asking if the person agreed.
Early in the AADS chip strawman
https://www.garlic.com/~lynn/x959.html#aads
and X9.59 work,
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
we realized that transactions needed to be directly signed, that it
should be possible for the digital signing (terminal) environment to
also sign the transactions, and that the relying party needed to have
access to both the token operational characteristics as well as any
terminal environment operation characteristics (in order to correctly
interpret and evaluate any meaning attached to the digital signatures
... as well as dynamic adaptive risk assesement).
this was one of the issues over the years involving the yes card
technology ... the token is authenticated separately from the
transaction operations ... opening various kinds of mitm-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
or various kinds of other end-point vulnerabilities. some recent
postings on yes card technology
https://www.garlic.com/~lynn/aadsm23.htm#2 News and Views
https://www.garlic.com/~lynn/aadsm22.htm#41 FraudWatch Chip&PIN
and is the issue in the SSL-evading trojans:
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature
again, another example where the end-point is authenticated separately
from the actual operations ... creating additional cracks and
vulnerabilities that may be exploited (MITM-attacks and/or
interception and modification).
of course, in the AADS model ... the relying party could obtain online
access to all of this information for correctly interpreting digital
signatures ... in a digital certificate-less paradigm
https://www.garlic.com/~lynn/subpubkey.html#certless
we also talked to some of the people behind the X.509V3 digital
certificate work and pointed out that such useful integrity
information might be significantly more interesting to a relying party
than anything that might be found in a CPS statement.
FraudWatch - Chip&Pin, a new tenner (USD10)
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2006 10:57 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
Petrol giant Shell has suspended chip-and-pin payments in 600 UK
petrol stations after more than £1m was siphoned out of customers'
accounts.
http://news.bbc.co.uk/2/hi/uk_news/england/4980190.stm
re:
https://www.financialcryptography.com/mt/archives/000673.html
previous post in this thread:
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin
misc. collected fraud, vulnerabilities, threats, exploit posts
https://www.garlic.com/~lynn/subintegrity.html#fraud
FraudWatch - Chip&Pin, a new tenner (USD10)
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2006 10:57 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000673.html
https://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch - Chip&Pin
and some late breaking:
Eight held over chip and pin fraud
http://www.guardian.co.uk/uklatest/story/0,,-5803656,00.html
Eight held over chip and pin fraud
http://www.thisislondon.co.uk/news/articles/PA_NEWA19204681146904793A00?source=PA%20Feed
Eight held over chip and pin fraud
http://www.24dash.com/content/news/viewNews.php?navID=34&newsID=5478
the above implies that the chip passes an image of magstripe
information as part of the communication ... and that this information
is being skimmed (possibly the magstipe image is included in some form
of digital certificate and/or the chip terminal is designed in such a
way that it simultaneously establishes chip communication and reads
the magstripe?).
the skimmed information (from the chip?) is then used to counterfeit a
magstripe card ... which is then used for fraudulent (magstripe)
transactions (replay attack of static data)
it mentions that the PIN is also being skimmed which is then available
for fraudulent (magstripe) pin-debit transactions. the implication
then is that the chip's PIN is the same as the magstripe debit PIN
(replay attack of static data)
Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 6, 2006 10:48 AM
Subject: Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000709.html
https://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera
Trusted Web Sites Not Always Trustworthy, Says Noted Computer Security
Researcher
http://biz.yahoo.com/prnews/060505/sff027.html?.v=48
with respect to today's news articles on chip&pin fraud
https://www.garlic.com/~lynn/aadsm23.htm#16
https://www.garlic.com/~lynn/aadsm23.htm#17
a post in the original thread
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin
about chip&pin not being usable on the Internet because of
vulnerabilities ... possibly similar skimming related vulnerabilities
(for replay attacks).
Note that some of the vulnerabilities mentioned in this thread are
similar to those faced when deploying corporate vpn for access by
traveling and at-home employees.
some of this first showed up when employees would attach dial-up
modems to their PCs and work and dial the internet. these PCs (when
also connected to the internal corporate intra-net) allowed attackers
to bridge attacks thru the dial-up connection, bypassing the corporate
firewalls.
later with off-site VPN connections, the remote employee PCs required
an internet connection in order to tunnel the VPN connection into the
corporate network. Lots of the personal PC VPN implementations added
all sorts of countermeasures attempting to keep attackers from
using the PC to bridge into the corporate network (bypassing corporate
firewalls).
a lot of these corporate VPN-related countermeasures (attempting to
prevent attackers from using employee's PC internet connection to
bridge into the corporate network) ... have been specifically directed
at virus/trojan related vulnerabilities.
Petrol firm suspends chip-and-pin
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 6, 2006 11:46 AM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000713.html
some of the details are obscured. it seems that information is being
skimmed in a chip&pin transactions to create a counterfeit
magstripe cards. possibly both magstripe credit transactions and
apparently also magstripe pin-debit transactions (using the pin
entered during chip&pin transactions).
what isn't clear is whether the skimming of the magstripe information
comes from physically reading the magstripe on a chip&pin card
(during a chip&pin transaction) or if there is an image of the
magstripe transmitted during the chip&pin transactions (which can
be evesdropped). Basically using static data based authentication for
replay attacks.
as mentioned in the earlier posts ... there have already been comments
about not using chip&pin for internet transactions because of
(some) vulnerabilities. internet vulnerabilities tend to either be
various kinds of phishing, skimming, harvesting, evesdropping (for
replay attacks):
https://www.garlic.com/~lynn/subintegrity.html#harvest
or mitm-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
recent posts
https://www.garlic.com/~lynn/aadsm23.htm#16
https://www.garlic.com/~lynn/aadsm23.htm#17
https://www.garlic.com/~lynn/aadsm23.htm#18
as previously noted, the financial standards x9a10 working group in
the mid-90s had been given the requirement to preserve the integrity
of the financial infrastructure for all retail payments ... this was
all as to type of payment (credit, debit, stored-value, e-check, ALL)
as well as environment (point-of-sale, face-to-face, non-face-to-face,
internet, ALL)
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
Petrol firm suspends chip-and-pin
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@garlic.com>
Date: May 7, 2006 09:26 AM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000713.html
CHIP AND PIN CARDS IN CHAOS
http://www.tmcnet.com/usubmit/-chip-p-cards-chaos-/2006/05/07/1639879.htm
from above:
Association's spokeswoman Sandra Quinn said: They have used an
old-style skimming device. They are skimming the card and copying the
magnetic details.
... snip ...
Eight arrests in GLB1m fraud
http://scotlandonsunday.scotsman.com/index.cfm?id=684712006
from above:
Spokeswoman Sandra Quinn said: They are skimming the card, copying
the magnetic details - there is no new fraud here.
... snip ...
Petrol firm suspends chip-and-pin
http://news.bbc.co.uk/1/hi/england/4980190.stm
however, from above:
A Shell spokeswoman said: Shell's chip-and-pin solution is fully
accredited and complies with all relevant industry standards.
Chip and pin machine Chip and pin cards are designed to prevent fraud
We have temporarily suspended chip-and-pin availability in our UK
company-owned service stations.
This is a precautionary measure to protect the security of our
customers' transactions.
You can still pay for your fuel, goods or services with your card by
swipe and signature.
... snip ...
??? so if it is ok to swipe your magstripe ... where is the
information being skimmed (for production of a counterfeit magstripe
card) ... is it possible an copy of the magstripe information is also
in the chip and is being skimmed by evesdropping the chip protocol?
past posts in this thread &/or refs to yes card:
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#18 Security Soap Opera
https://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends Chip&Pin
Reliable Connections Are Not
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 7, 2006 11:06 AM
Subject: Reliable Connections Are Not
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000714.html
we had done a high-speed backbone in the mid-80s and had to address
lots of these issues.
https://www.garlic.com/~lynn/subnetwork.html#hsdt
in the late 80s & early 90s were on the XTP (protocol) technical
advisory board ... which had a specification that addressed a number
of these issues. one of the participants was from the naval surface
warfare center (nswc) ... they were looking at using it for shipboard
fire control systems ... and were assuming an extremely hostile
environment with possibly significant failure scenarios.
it was also billed as high-speed operation ... including having a
reliable datagram delivery.
one of the comparisons that was done at the time was that TCP/IP
requires a minimum 7-packet exchange. at the time, there had been work
on VMTP (RFC1045) for "reliable" protocol in minimum 5-packet
exchange. XTP was specifying a reliable protocol in minimum 3-packet
exchange.
misc. past posts mentioning XTP and/or its proposal in ANSI/ISO as
high-speed protocol.
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
one of the things that plagued webservers in the early days was that
most tcp/ip implementations had assumed relatively long running
sessions. as a result, the termination processing had processing of
linear lists (FINWAIT). One of the first mismatches between HTTP (as a
datagram protocol) implementations in TCP (a session protocol) was
when some number of webservers were finding that the CPU was spending
95% of its time running through FINWAIT processing (the high-rate of
extremely short sessions was resulting in extremely long FINWAIT
lists).
when we were asked to consult with this small client/server startup
that wanted to do payment transactions on the server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
which is now commonly referred to as e-commerce. a lot of people
assumed that you could take the message format definitions from the
payment industry telco circuit-based operation and map it into a
tcp/ip packet network. the messages flowed ... but it had none of the
traditional telco industry provisioning that come to be implicitly
assumed. An early test had a problem and a trouble call logged with
the payment transaction trouble desk. the trouble desk nominally
expected to do first level problem determination within five minutes
elapsed time. three hours later, they were still not able to resolve
what was going on and closed it as NTF. another issue was that
their SSL technology was dependent on being used in very specific
sequence of processes (which is frequently not observed these days).
out of that we spent several week doing a detailed failure mode
analysis and coming up with a bunch of documentation and processes as
compensating procedures for mapping a telco provisioned circuit
operation into a tcp/ip network.
some of this we were able to draw on earlier experience having
previously done an extremely detailed vulnerability analysis of tcp/ip
protocol as part of turning out our ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
where vulnerability included full gamut of operational type failures
as well as possibility of active attacks. recent post mentioning
another aspect of this
https://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
Payment systems - the explosion of 1995 is happening in 2006
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 7, 2006 05:35 PM
Subject: Payment systems - the explosion of 1995 is happening in 2006
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000711.html
slightly related post in a thread about paypal and financial services
offerings
it also mentions that several of the digital cash operations in the
90s were structured as a mechanism of acquiring the float on the money
in the infrastructure.
in the mid-90s some number of the central banks stated that they would
allow the operations to retain the float through startup phases but
after that they would be required to start paying interest on the
customers' value on deposit in the infrastructure.
this somewhat put a damper on some amount of digital cash ventures
related to starting and operating such infrastructures (that they
would not be able to count on the large float bonanza):
https://www.garlic.com/~lynn/2006i.html#14
Payment systems - the explosion of 1995 is happening in 2006
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2006 11:43 AM
Subject: Payment systems - the explosion of 1995 is happening in 2006
MailingList: Financial Cryptography
Iang wrote:
Lynn, was that in the US or in Europe? I can well
imagine that Mondex were told the float would be
regulated ... because they based their business
case on such float capture issues and tried to
reserve it to Mondex International. Such an
amusing selling technique :)
re:
https://www.garlic.com/~lynn/aadsm23.htm#22 Payment systems - the explosion of 1995 is happening in 2006
the central banks I remember making the statement were mostly in
europe. many of the "stored value" digital cash systems are at least
partially based on float providing financial incentive.
one of the big issues in the early e-check operation was whether the
funds would settle immediately electronically or take several
days. some of the financial institutions were use to the float
operation of the physical check world. this was also raised in the
recent check21 mandates and how long would it take funds to actually
settle.
with respect to mondex, we had been asked to design and cost an
infrastructure for a national deployment ... as part of that we also
did a business analysis of the financials. they were looking at
charging fees for fund transfers into the card as well as loosing the
float. part of this was that the float (originally) effectively all
rolled up to mondex international ... so the other institutions in the
infrastructure had to recover their costs by other mechanisms.
misc. past posts mentioning float and/or mondex
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
https://www.garlic.com/~lynn/aepay11.htm#42 Bank Float May Sink
https://www.garlic.com/~lynn/aadsm14.htm#7 Bank Float May Sink
https://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
https://www.garlic.com/~lynn/2005u.html#29 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure?
Reliable Connections Are Not
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2006 02:40 PM
Subject: Reliable Connections Are Not
MailingList: Financial Cryptography
blog:
https://www.financialcryptography.com/mt/archives/000714.html
part of doing ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
we had a bunch of stuff that did ip-address take-over when a
server/router failed (we also had stuff to do MAC-address take-over)
for fall-over.
part of this was dependent on ARP table time-outs of the
ip-address->MAC-address (so a different MAC-address could come in with
the same MAC-address).
turns out that it wasn't working very well. there was a bug in bsd
tahoe/reno implementation that was in used by a large number of
different platforms (so any client platform network code built using
the bsd tahoe/reno code base had the problem).
the ip-address to mac-address routine saved the last response from
calling the ARP routine. if the next request was for the same
ip-address, the code would use the saved response ... rather than
(re-)calling the ARP routine. this saved response had no time-out
(compared to the table entries managed by the ARP routine). ARP flush
command had no effect on this saved value either.
so a large number of client configurations were heavily asymmetric
traffic ... nearly all client traffice going through/to a server or
router.
so an administrative work-around was to send a packet from a
"differnet" ip-address to the list of all clients. this would force
the clients ip-address to do a lookup on a different ip-address
(resetting the single saved value and forcing a call to the ARP code).
posts in thread:
https://www.garlic.com/~lynn/aadsm23.htm#21 Reliable Connections Are Not
https://www.garlic.com/~lynn/2006i.html#16 blast from the past, reliable communication
https://www.garlic.com/~lynn/2006i.html#17 blast from the past, reliable communication
Petrol firm suspends chip-and-pin
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2006 06:23 PM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000713.html
this shows a picture of a smart 5000 ped
http://linuxdevices.com/articles/AT5376216178.html
it seems that if you do a magstripe op ... the card goes in
horizontal(?) but if you want to do a chip, the card goes in
veritically(?). if that is the case, the magstripe wouldn't be read if
doing a pin operation?
a possible question was whether chip&pin had an image of the
magstripe in the chip which is transferred to the terminal embedded in
some protocol chatter. somebody might have specified such a protocol
since it would minimize the deployment impact for chip&pin on
the rest of the infrastructure (i.e. after some amount of the chip
protocol chatter at the terminal ... a payment transaction could go
thru a lot of backend processing with the emulated track1&track2
data).
this might account for one of the news items where Shell said that
chip&pin was being disabled ... but that transactions could still be
done with magstripe swipe.
also this was the chip&pin yes card scenario mentioned in the
previous thread, the chip/terminal communication was evesdropped and
the skimmed information was used to create a counterfeit (chip&pin)
chip
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin
this however shows a more traditional ATM looking card reader
http://www.openpaynews.com/downloads/datasheets/openpayUPT-4000.pdf
another picture (again looks like it is capabile of reading both the
magstripe and chip in same operation)
http://www.trintech.com/Unattended-Payment-Terminals-OpenPay-UPT-4000.html
how does it select between doing a magstripe operation vis-a-vis chip
operation ... if the card has been inserted in such a way that it
reads both?
i found a webpage describing a hybrid emv/magstripe reader that talks
about simultaneously reading the magstripe and the emv chip and
validating the two sets of information being consistent.
This article dated feb. 7, 2006 talks about being able to skim
magstripe on a emv card and using the information to create
counterfeit magstripe cards
http://australianit.news.com.au/articles/0,7204,18033140%5E15397%5E%5Enbv%5E,00.html
Petrol firm suspends chip-and-pin
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2006 06:48 PM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
Chip and pin hack exposed
http://www.theinquirer.net/?article=31547
According to our source, a team of shysters has been turning up at
petrol stations posing as engineers and taking the Trintech Smart5000
Chip and Pin units away for repair. They have then bypassed the
anti-tamper mechanisms and inserted their own card skimmer.
... snip ...
this is also could be considered from the angle of my old security
proportional to risk theme
https://www.garlic.com/~lynn/2001h.html#61
previous posts in this thread:
https://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch Chip&Pin
https://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch Chip&Pin
https://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends Chip&Pin
https://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends Chip&Pin
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends Chip&Pin
Chip-and-Pin terminals were replaced by "repairworkers"?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 9, 2006 10:36 AM
Subject: Chip-and-Pin terminals were replaced by "repairworkers"?
MailingList: Financial Cryptography
Shell Chip And PIN Breach - Response From RSA Security
http://www.theitshield.com/pr/7118
can you say security proportional to risk
https://www.garlic.com/~lynn/aadsm23.htm#26 Petrol firms suspends chip-and-pin
and
https://www.garlic.com/~lynn/2001h.html#61
or parameterised risk management
https://www.garlic.com/~lynn/aadsm23.htm#1
note that the chip&pin counterfeit yes card chips mentioned in 2002 reference
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
and
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin
would have involved compromised and/or counterfeit chip&pin readers
skimming information (for loading into the counterfeit chips) from the
chip&pin protocol chatter.
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
JIBC April 2006 - "Security Revisionism"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2006 01:11 PM
Subject: JIBC April 2006 - "Security Revisionism"
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000717.html
http://www.arraydev.com/commerce/JIBC/2006-04/Grigg.asp
with respect to comment about doubling costs:
Adi Shamir suggests that to double security we have to
double costs [ 11 ]. The specific failings of the '90s
generation were an over-attention on a perfect security
model, which resulted in usability issues on the one hand,
and crowding out other ideas primarily with public key
infrastructures ("PKIs") on the other. We will pay the
price for this in phishing for the next couple of years,
until PKI is overcome.
in the mid-90s, when x9a10 financial standards working group was given
the requirement to preserve the integrity of the financial
infrastructure for all retail payments (in the work on x9.59
standard) ... one of the questions was can you eliminate the
vulnerability ... as opposed to providing stronger security as a
countermeasure to the vulnerability.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
at the time, skimming was well-established ... harvesting static data
for use in replay attacks. at the time, part of this was that
the account number was effectively overloaded with both account lookup
function (used in large number of different business processes) and
effectively, also, as form of authentication. x9.59 addressed the
opportunity by establishing that account numbers had nothing at all to
do with authentication ... and that there needed to be dynamic
data authentication that was not subject to skimming and replay
attacks.
https://www.garlic.com/~lynn/subintegrity.html#harvest
the other thing that was fairly well recognized was
man-in-the-middle attacks, especially where authentication was
used to bracket some number of operations or transactions. The
operations/transactions themselves were performed w/o being directly
authenticated. x9.59 required that dynamic data authentication
(countermeasure to skimming and reply attacks) be applied
directly to all operations (countermeasure to various kinds of
man-in-the-middle attacks).
https://www.garlic.com/~lynn/subintegrity.html#mitm
eliminating the vulnerabilities was a significant better approach to
providing for cost-effective security, as opposed to attempting to
pile-on ever increasing amounts of security to cover up problems. this
is somewhat my past serious of posts mentioning that burying the
planet under miles of cryptography would never be the solution for
several of these vulnerabilities. note that at the time the
x9.59 work was starting, there was still quite a bit of gov. &
jurisdictional issues around the world with the use of crypto for
hiding information, x9.59 changed the paradigm so it was no longer
necessary to hide the transaction as fraud countermeasure:
https://www.garlic.com/~lynn/aadsm15.htm#21 Simple SSL/TLS - Some Questions
https://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
https://www.garlic.com/~lynn/2005k.html#56 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
https://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
https://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
https://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006h.html#26 Security
JIBC April 2006 - "Security Revisionism"
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2006 03:04 PM
Subject: JIBC April 2006 - "Security Revisionism"
MailingList: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm23.htm#28 "Security Revisionism"
Adi Shamir suggests that to double security we have to
double costs [ 11 ]. The specific failings of the '90s
generation were an over-attention on a perfect security
model, which resulted in usability issues on the one hand,
and crowding out other ideas primarily with public key
infrastructures ("PKIs") on the other. We will pay the
price for this in phishing for the next couple of years,
until PKI is overcome.
and with respect to the above comment about the failings of the 90s
... was that some number of these fledgling, new startups calling
themselves certification authorities ... had approached the financial
industry with a business proposal for certificate manufacturing
... a term we had coined at the time
https://www.garlic.com/~lynn/subpubkey.html#manufacture
the financial institutions would register public keys for each of
their accounts and transmit the updated master account file to one of
these fledgling, new startup certification authorities. the
certification authority would manufacture a digital certificate based
on the information in each account record and return the results to
the financial institution at only a charge of $100/account/annum. This
represented a minimum of $20b/annum transfer of wealth from financial
infrastructure to these fledgling certification authority startups.
many in the industry had been convinced that the only security was
provided by validating digital signatures using public keys taken from
appended digital certificates and there was absolutely no
security provided by validating digital signatures using on-file
public keys taken from account records (even in cases where the
digital certificate content had been totally derived from the same
account record).
my observation that this minimum $20b/annum costs for something that
provided no incremental security (over using the same information
directly from the account record) created a significant barrier to
market entry.
one indication of such pervasive belief in the requirment (for digital
certificates for digital signature validation), was an effort in the
financial standards group on compressed digital certificates. the
problem was that typical payment transaction was on the order of 60-80
bytes ... even for relying-party-only certificate infrastructure
https://www.garlic.com/~lynn/subpubkey.html#rpo
would contribute an appended 4k-12k bytes resuling in a transaction
payload bloat of 100 times (thousands of bytes rather than tens of
bytes)
the objective of the compessed digital certificate effort was
attempting to get the appended overhead down on the order of 300 bytes
(initially by removing non-unique fields in every certificate).
However, I suggested that even a better method was to remove every
field that was already in the possession of the relying party. For the
situation where the digital certificate had been totally derived from
the financial institution's account record, it was trivially possible
to demonstrate compression of a digital certificate to zero
bytes. misc. past posts mentioning the enormous payload bloat
of normal digital certificates and the significant
payload bloat reduction by appending zero-byte digital
certificates:
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#10 X.500, LDAP Considered harmful Was: OCSP/LDAP
https://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server
https://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#5 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#27 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
https://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation
https://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm19.htm#40 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/2003g.html#47 Disk capacity and backup solutions
https://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
https://www.garlic.com/~lynn/2004g.html#5 Adding Certificates
https://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
https://www.garlic.com/~lynn/2004m.html#23 Help! I'm trying to understand PKI - especially CA's role
https://www.garlic.com/~lynn/2005e.html#22 PKI: the end
https://www.garlic.com/~lynn/2005e.html#38 xml-security vs. native security
https://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
https://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#45 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005h.html#25 couple more Q's on basic public key encryption techniques
https://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
https://www.garlic.com/~lynn/2005i.html#4 Authentication - Server Challenge
https://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
https://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
https://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
https://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
https://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
https://www.garlic.com/~lynn/2006e.html#42 SSL Certificate Signing
https://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#28 confidence in CA
https://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation
Petrol firm suspends chip-and-pin
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2006 05:59 PM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
some of the comments in the news today:
Security Expert Says Chip-And-PIN Facilitates ATM Fraud
http://www.cardtechnology.com/article.html?id=20060510KWGALG2S
'Fraudproof' cards attract scammers
http://www.channel4.com/news/content/news-storypage.jsp?id=447024
'Fraudproof' cards attract scammers
http://www.itn.co.uk/news/index_447024.html
'Fraudproof' cards attract scammers
http://www.itv.com/news/index_447024.html
Old technology aiding identity fraud
http://www.smh.com.au/news/national/old-technology-aiding-identity-fraud-keelty/2006/05/10/1146940613348.html
as mentioned previously, the comment from 2002 on chip&pin yes
card
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
and
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin
fraud (which had been going on up to that time), was with respect to
compromised or counterfeit terminals skimming the chip&pin protocol
chatter ... not (necessarily also) skimming the magstripe.
the chip&pin specification here mentions "track1" and "track2"
(i.e. the components of the magstripe) in the chip protocol chatter
http://gsho.thur.de/gsho/technik/download/cardspec.pdf
http://www.ttfn.net/techno/smartcards/termspec.pdf
... this is in addition to having the PIN in the chip protocol
chatter.
so one question is whether that information (in the chip protocol)
sufficiently similar to that used for the magstripe, that it enables
the creation of counterfeit magstripes?
the specification also talks about the signed static application
data ... which was what was used for authentication in the yes
card scenarios.
the "dynamic data" (authentication option) in the specification is
supposedly a countermeasure to the replay attacks found
with the counterfeit (static data) yes cards. one issue may be that
since "static data" is part of the specification, 1) can sufficient
data be skimmed in a "dynamic data" transaction; and 2) then can that
data be used to build counterfeit yes card; and 3) can such a
yes card convince terminals to downgrade from "dynamic data" to
"static data" operation?
a possible alternative scenario is can a compromised or counterfeit
terminal convince a "good" chip to downgrade from "dynamic data" to
"static data", skim the "static data" ... and then use that to build
counterfeit yes cards?
other details in the specification talks about the chip containing
sufficient business rules for authorizing offline transactions
... which also contributed to the rise of the yes card label
... aka the terminal would ask an "authenticated" card whether to do
an offline transaction, and if YES, also ask the card if the
transaction should be approved.
JIBC April 2006 - "Security Revisionism"
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2006 09:41 AM
Subject: JIBC April 2006 - "Security Revisionism"
MailingList: Financial Cryptography
for your reading pleasure
Security Absurdity: The Complete, Unquestionable,
And Total Failure of Information Security.
http://www.securityabsurdity.com/failure.php
and of course, old post on thread between information security
and risk management
https://www.garlic.com/~lynn/aepay3.htm#riskm
and security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
with respect to one of the references in the above article, some old
news items (not sure if they are all still active):
Cybercrime Profits Outpace Drug Trafficking
http://www.ecommercetimes.com/story/47559.html
Expert: Cyber-crime Yields More Cash than Drugs
http://www.eweek.com/article2/0,1895,1893592,00.asp
Expert: Cyber-crime Yields More Cash than Drugs
http://www.extremetech.com/article2/0,1697,1893916,00.asp
Cybercrime now outstrips drug trafficking
http://www.cw360asp.com/Articles/2005/11/29/213190/Cybercrimenowoutstripsdrugtrafficking.htm
Cybercrime 'more lucrative' than drugs
http://www.theregister.co.uk/2005/11/29/cybercrime/
Cybercrime profits exceed those of drugs, expert says
http://www.globetechnology.com/servlet/ArticleNews/TPStory/LAC/20051129/RTICKERB29-2/TPTechnology/
Cybercrime yields more cash than drugs
http://news.com.com/Cybercrime+yields+more+cash+than+drugs/2100-7348_3-5973918.html
Cybercrime 'more lucrative' than drugs
http://www.theregister.com/2005/11/29/cybercrime/
Cybercrime 'more lucrative' than drugs
http://www.channelregister.co.uk/2005/11/29/cybercrime/
Cybercrime more profitable than illicit drug sales?
http://arstechnica.com/news.ars/post/20051129-5648.html
Chip-and-Pin terminals were replaced by "repairworkers"?
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2006 09:54 AM
Subject: Chip-and-Pin terminals were replaced by "repairworkers"?
MailingList: Financial Cryptography
more in the on going saga
Lloyds TSB admits chip and Pin flawed
http://www.thisismoney.co.uk/saving-and-banking/article.html?in_article_id=408976&in_page_id=7
Bank admits flaws in chip and PIN security
http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=385811&in_page_id=1770
Surge in overseas ATM fraud
http://www.itn.co.uk/news/business_341509.html
Surge in overseas ATM fraud
http://www.channel4.com/news/content/news-storypage.jsp?id=341509
in 2000 there was a one week conference in London with the Lloyds of
London syndicates that provide retail fraud insurance. One of the
subjects discussed extensively was the threat model involving
compromised and counterfeit terminals for things like skimming ... as
well as x9.59 characteristic of having eliminated requirement to hide
the transaction as fraud countermeasure.
slight cross-over
https://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
Chip-and-Pin terminals were replaced by "repairworkers"?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2006 10:30 AM
Subject: Chip-and-Pin terminals were replaced by "repairworkers"?
MailingList: Financial Cryptography
Iang wrote:
Lynn, who/which was taking out the insurance? Why
weren't they self-insuring? It seems with such a large
and spread population only self-insurance makes sense?
re:
https://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?
retail merchants (brick&mortar) ... many places in the world.
for payment cards ... the retail merchant having fraudulent
transactions is held liable for the transactions. standard dispute
process ... and burden of proof is on the merchant in any dispute.
for a little drift ... a few past posts mentioning disputes
https://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
https://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
Chip-and-Pin terminals were replaced by "repairworkers"?
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2006 04:20 PM
Subject: Chip-and-Pin terminals were replaced by "repairworkers"?
MailingList: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#33 Chip-and-Pin terminals were replaced by "repairworkers"?
looking at the threat model for compromised and/our counterfeit
terminals was attempting to get a feeling for production of
counterfeit cards that could be used at other merchants for fraudulent
transactions (and therefor overall merchant fraud).
the early x9.59 protocol analysis from the mid-90s had the transaction
being directly authenticated.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
separation of authentication from the actual operations tends to
mimick more of session type paradigm. however, session type paradigm
(with authentication separate form actual operations), tends to be
more vulnerable to end-point compromises, infrastructure compromises,
replay attacks, mitm-attacks, etc.
In the past, physical compromises of end-points (like terminals) or
infrastructure (like networks) have tended to involve evesdropping and
harvesting related exploits. the attackers would take the gathered
information and use it for mounting attacks on other parts of the
infrastructure. Part of this can be viewed from the standpoint of
fraud ROI ... it takes some amount of investment to put into play
compromised (or counterfeited) end-points amd/or other parts of the
infrastructure (like network). Using information from the exploit to
attack other parts of the infrastructure, draws attention and
suspicion away from the point of exploit (tending to maximise its
criminal operation). Performing fraudulent transactions at the point
of exploit tends to focus suspicion much quicker, the implication that
the point of exploit will be discovered and have a much shorter useful
(criminal) lifetime. This has tended to be the model for compromised
and/or counterfeit terminals.
However, the economics somewhat change in the online/virtual
world. Getting a trojan/virus into a personal computer end-point tends
to represent much lower investment. The trojan/virus can operate as a
compromised terminal, havesting/skimming information that enables
attacks at other points of the infrastructure. However, the
trojan/virus can also be used to directly perform fraudulent
operations. This may shorten the life expectency of the trojan/virus
... but it doesn't take a lot of such fraud for an attacker to recover
their expenses.
as oft repeated before, the requirements given the x9a10 standards
working group for x9.59 standard was to preserve the integrity of the
financial infrastructure for ALL retail payments.
part of those requirements, implied x9.59 requiring dynamic data
authentication (digital signatures) as countermeasure to
skimming/harvesting (potentially by compromised or counterfeit
end-points) and replay attacks.
https://www.garlic.com/~lynn/subintegrity.html#harvest
however, it also implied that authentication be applied directly to
the transaction, drastically reducing the susceptability to various
kinds of other end-point and infrastructure vulnerabilities as well as
mitm-attacks.
https://www.garlic.com/~lynn/subintegrity.html#mitm
misc. past posts mentioning compromised and/or counterfeit terminals.
https://www.garlic.com/~lynn/aadsm19.htm#38 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm22.htm#44 Creativity and security
https://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
https://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
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004l.html#31 Shipwrecks
https://www.garlic.com/~lynn/2005g.html#41 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
3 of the big 4 - all doing payment systems
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 12, 2006 02:35 PM
Subject: 3 of the big 4 - all doing payment systems
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000715.html
... slight drift, another article from today
Payments Technologies Vie For Banks' IT Dollars
https://web.archive.org/web/20060526221137/http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1147439455861413176&block=
from above:
Payments revenues at European banks typically represent 10 per cent of
annual revenues, while in the US, this figure is nearer to 40 per cent
... snip ...
some difference in the revenue demographics between US and Europe
with regard to payment operations
3 of the big 4 - all doing payment systems
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 12, 2006 04:45 PM
Subject: 3 of the big 4 - all doing payment systems
MailingList: Financial Cryptography
Iang wrote:
Off to Washington DC they trotted and fairly soon on, the
message filtered back to Microsoft - that's not a good
idea, pick on someone else's soft underbelly.
re:
https://www.financialcryptography.com/mt/archives/000715.html
a congressman's speech on the floor of the senate about the bank
modernization act said that the purpose of the bill was if you are
already a bank, you can remain a bank and if you aren't already a
bank, you can't be a bank, and the bill was to specificially prevent
microsoft and wal-mart from becoming banks.
a couple other articles from today:
Small Banks Adopt a Wide Spectrum of Electronic Payments
http://www.digitaltransactions.net/newsstory.cfm?newsid=944
Home Depot: No Designs on Payments with Deal to Buy ILC
http://www.digitaltransactions.net/newsstory.cfm?newsid=945
from above:
Less than a month after the Federal Deposit Insurance Corp. held three
days of unprecedented hearings on Wal-Mart's application to
open a Utah ILC, Atlanta-based Home Depot this week disclosed a
definitive agreement to buy EnerBank USA, a Salt Lake City-based ILC
with $75 million in net loan assets.
... snip ...
3 of the big 4 - all doing payment systems
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 13, 2006 02:10 PM
Subject: 3 of the big 4 - all doing payment systems
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000715.html
https://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/aadsm23.htm#36 3 of the big 4 - all doing payment systems
another aspect of the payment industry landscape:
Interchange Fees: The tipping point
http://www.cyberwarzone.com/united-states-leaking-1tb-data-daily-foreign-countries
from above
Fed up with out-of-control interchange fees, retailers are fighting
back with concerted legal and educational tactics -- and, in some
cases, proactive offensives of their own.
... snip ...
http://www.epaynews.com/newsletter/epaynews322.html
from above:
Convenience store operators can make more money on a 12-ounce cup of
coffee than they can on a 12-gallon tank of gas. Credit card fees now
account for almost half of a typical store's expenses - more than
labor.
... snip ...
this is sort of another facet of Boyd OODA-loops ... not only do you
cycle the loops faster ... but during the loop you may also view a
subject from a number of different aspects.
https://www.garlic.com/~lynn/subboyd.html#boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
NSA knows who you've called
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: NSA knows who you've called.
Date: Sat, 13 May 2006 17:02:57 -0600
To: cryptography@xxxxxxxx
dan@xxxxxxxx wrote:
You and I are in agreement, but how do we get
the seemingly (to us) plain truth across to
others? I've been trying for a good while now,
reaching a point where I'd almost wish for a
crisis of some sort as persuasiveness is not
working.
for other drift ... the stuff about call record analysis with regard
to social networking has been topic in datamining conferences for the
past several years ... both academia and industry. the cellphone
companies appear to be especially interested in it, for various kinds
of capacity planning and marketing purposes (I think some academia
even have contracts with cell phone companies researching this area).
several months ago my wife had extensive communication with an editor
doing some background stuff on datamining. some of it showed up in an
article somewhat spun for the current situation
Info Mining & Sharing are Controversial Co-Dependents, part 1:
https://web.archive.org/web/20070312195254/http://www.publicsectorinstitute.net/ELetters/EGovernment/v4n7/May13Articles.lsp#DataMining2
my wife's quotes liberally lace part 2:
Data Mining "Disrupts & Enables"
http://www.publicsectorinstitute.net/ELetters/EGovernment/v4n7/May13Articles.lsp#DataMining2
Tracking you, tracking me, tracking everyone
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 14, 2006 10:46 AM
Subject: Tracking you, tracking me, tracking everyone
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000704.html
minor related reference from crypto list posting
https://www.garlic.com/~lynn/aadsm23.htm#38 NSA knows who you've called
there was some recent announcement (I forget where I saw it) that
somewhere they are going to start sending location specific
advertisements to your cellphone ... as you move from place to place
... they will transmit advertisements to your cellphone that are
specific to your current physical location.
Markets in Imperfect Information - Lemons, Limes and Silver Bullets
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 15, 2006 11:27 AM
Subject: Markets in Imperfect Information - Lemons, Limes and Silver Bullets
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000721.html
part of this drifts into the area when something appears to be
valuable ... and there are items that are taken as representations of
that something ... then you have people inclined to fraud. in various
of my postings on credentials, certificates, diplomas, licenses, etc
that have served for centuries as representation paradigm (for
replying parties that have no direct knowledge and/or means of
obtaining that knowledge) ... education has become a valuable
commodity and diplomas that are taken as representation of education,
are now being fabricated (either fraudulent and/or in diploma mills).
this is the scenario that there are various facts ... and for
centuries; credentials, certificates, diplomas, and licenses have been
used to represent various facts for relying parties that have not the
means of directly accessing the facts themselves. with advances in
dataprocessing and online networks there are fewer and fewer
circumstances where relying parties can't find some means of accessing
the facts ... drastically reducing the situations where separate and
distinct credentials, certificates, diplomas, and/or licenses are
required (as a means of representing such facts).
this is sort of the certificate sticker on the window of a used car
vis-a-vis getting something like a carfax report.
misc. past posts mentioning the centuries old paradigm of credentials, certificates, diplomas and/or licenses for relying parties that don't have any other means of accessing the information
https://www.garlic.com/~lynn/aadsm23.htm#0 Separation of Roles - an example
https://www.garlic.com/~lynn/aadsm23.htm#5 History and definition of the term 'principal'?
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/2006c.html#13 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#36 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#39 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#28 confidence in CA
https://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation
3 of the big 4 - all doing payment systems
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 15, 2006 11:37 PM
Subject: 3 of the big 4 - all doing payment systems
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000715.html
https://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/aadsm23.htm#36 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
Plastic under attack. Battling lawsuits and new rivals, MasterCard and
Visa may face a lower-growth future.
http://money.cnn.com/magazines/fortune/fortune_archive/2006/05/29/8377961/index.htm
....
ECOM Finds Issuer for Anonymous, Disposable Prepaid MasterCard
http://www.digitaltransactions.net/newsstory.cfm?newsid=954
from above
... allows the company to sell the cards to consumers through
merchants like cans of soda or other merchandise, then process
transactions almost immediately at any location that takes MasterCard
... snip ...
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
Date: Tue, 16 May 2006 17:24:53 -0600
To: Cryptography <cryptography@xxxxxxxx>
https://www.garlic.com/~lynn/rfcidx14.htm#4492
4492 I
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
Layer Security (TLS), Blake-Wilson S., Bolyard N., Gupta V., Hawk C.,
Moeller B., 2006/05/16 (35pp) (.txt=72231) (Refs 2246, 3268, 3279,
3280, 4346, 4366) (was draft-ietf-tls-ecc-12.txt)
Spring is here - that means Pressed Flowers
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 22, 2006 12:37 PM
Subject: Spring is here - that means Pressed Flowers
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000729.html
the referenced digital money blog ... in turn has a reference to
Schneier's blog on multi-use smartcards ... which has a post
mentioning the amex blue card for consumer use.
http://www.schneier.com/blog/archives/2006/02/multiuse_id_car.html
part of the program was giving away "free" smartcard readers. at the
time the "pc/sc" standard only supported serial port ... and the
distributed smartcard readers were serial port devices. consumers had
horrendous problems with getting serial port smartcard readers
installed and operational. there were horror tales about 1hr customer
call center conversations that were unable to resolve and large number
of stories about repeated blue screens of death during install
attempts and even people being forced to re-install their systems from
scratch.
this experience with serial port pc/sc eventually resulted in an
industry opinion that smartcards were not viable in the consumer
market segment. it was also during this period that m'soft announced
they were canceling their smartcard operating system project.
there was subsequent effort that upgraded pc/sc standard to USB
plug&play, which turned out to address many of the problems
experienced during the earlier activity with serial port smartcard
readers. however, by this time, there was a fairly widespread opinion
that smartcards were not viable in the consumer market segment.
for total drift ... i have slight quible with some nomenclature
differentiating multi-application smartcards and multi-function
smartcards.
it is possible to have a chipcard that just does a single function
... like authentication ... and that single function can be used in a
large number of different applications ... resulting in it being a
multi-application card (even if the chip only does a single function).
that is separate from multi-function smartcards that implement lots of
different functions possibly for use in a wide-variety of different
applications. part of the approach of the multi-function smartcards
was left from the 80s & 90s when they were supposed to be the
low-end portable computing vehicle ... only to find that they were
displaced from that market segment by PDAs and cellphones.
recent ref (last part of the post) consulting with gov. lab in the
early 90s on trying to move gov. technology into commercial sector
... including some smartcard technology
https://www.garlic.com/~lynn/2006k.html#25
part of this orientation has also led to things like embedding
significant business rules in the smartcard ... this was at least part
of the issue with the yes card exploits mentioned in previous
threads
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
https://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
https://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
ThreatWatch - markets in loss, Visa's take, 419 "chairmen"
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 23, 2006 07:52 PM
Subject: ThreatWatch - markets in loss, Visa's take, 419 "chairmen"
MailingList: Financial Cryptography
https://www.financialcryptography.com/mt/archives/000727.html
a couple years ago a study was published claiming that 70percent of
identity theft involved insiders. so in much the same way that the
amateurs provide cover for the professionals ... all the attention
placed on intrusion prevention and outsider countermeasures can cloak
the activities of the insiders.
at some point embezzlement and things like the S&L crisis represented
more of a threat to financial institutions than the guys with guns.
old post discussing the S&L crisis (among other things)
https://www.garlic.com/~lynn/aepay3.htm#riskm
Status of SRP
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Fri, 02 Jun 2006 19:09:41 -0600
To: cryptography@xxxxxxxx
Florian Weimer wrote:
If you've deployed two-factor authentication (like German banks did in
the late 80s/early 90s), the relevant attacks do involve compromised
customer PCs. 8-( Just because you can't solve it with your technology
doesn't mean you can pretend the attacks don't happen.
EU finread terminal was countermeasure to (widely held impression that)
PCs are extremely vulnerable to compromise.
https://www.garlic.com/~lynn/subintegrity.html#finread
card authentication required pin entry to work ... and finread
terminal had its own PIN-pad distinct from the vulnerable PC
keyboard. orientation was towards transaction authentication ... with
the finread terminal also having its own display of what was being
authentication. the transaction authentication orientation was
countermeasure to session authentication orientation where PC
compromises could operate within the boundaries of any authenticated
session.
part of thread in sci.crypt mentioning finread terminal as
countermeasure to (widely held view of) the ease of PC compromises
https://www.garlic.com/~lynn/2006k.html#46 Keylogger resistance
https://www.garlic.com/~lynn/2006k.html#52 Keylogger resistance
Status of opportunistic encryption
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of opportunistic encryption
Date: Fri, 02 Jun 2006 19:16:05 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
I was unaware of this. So I googled for DNSSEC. Reading
the DNSSEC documents I found
: : In order to support the larger DNS message
: : sizes that result from adding the DNSSEC RRs,
: : DNSSEC also requires EDNS0 support ([RFC
: : 671]).
and
: : its authentication keys can be authenticated
: : by some trusted means out of band from the
: : DNS protocol.
This does not sound workable to me.
this could be analogous or the same as the trusted certification
authority authentication keys that are incorporated into browsers when
they are distributed (to the extent that distributed certification
authority authentication keys, that are authenticated out of band from
the standard PKI process, appear to work, it could be possible that
something similar might also work for DNS).
the specification of the root DNS servers could include specifying the
associated authentication keys ... in much the same way that the
distribution of the root CAs information include the distribution of
the associated CA authentication keys.
my rfc index
https://www.garlic.com/~lynn/rfcietff.htm
select Term (term->RFC#) under RFCs listed by ... and then select
"DNSSEC" in the Acronym fastpath.
domain name system security (DNSSEC )
see also domain name system, domain name system extensions,
security
4509 4470 4431 4398 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
in frames mode, clicking on the RFC number brings up the RFC summary
in the lower frame. clicking on the ".txt=nnnn" field in the RFC
summary retrieves the actual RFC.
Status of opportunistic encryption
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of opportunistic encryption
Date: Fri, 02 Jun 2006 19:41:55 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm23.htm#46 Status of opportunistic encryption
oh, and some number of certification authorities actually backed some
parts of DNSSEC ... including the idea that people register a public
key when they registered a domain name. this was countermeasure to
various kinds of domain name hijacking vulnerabilities ... i.e. the
domain name owner would digitally sign communication ... and the
domain name infrastructure would validate the digital signature with
the onfile public key.
this became attractive to certification authorities. currently they
require a ssl domain name certificate application to supply a lot of
identification information. the certification authority then performs
the time-consuming, error prone, and expensive process of matching the
supplied identification information with the information on file with
the domain name infrastructure. with communication authenticated with
the onfile public keys, there is a reduction in the chance of domain
name hijacking ... and therefor the certification authority has higher
level of assurance that they aren't dealing with a ssl domain name
certificate applicant that has just hijacked the domain name.
also, if the public keys were on file with the domain name
infrastructure, then certification authorities could require that
application for ssl domain name certificates be digitally signed.
then the certification authorities could change from a time-consuming,
error prone, and expensive process of matching identification
information to the less-expensive and more reliable process of simply
authenticating the digital signature. they would execute dnssec
protocol with the domain name infrastructure requesting real-time
retrieval of the onfile public key for the domain name. they would
validate the response with DNSSEC trusted root public key on file in
their local repository of trusted dnssec public keys (in much the same
way that the existing PKI infrastructure validate digital signatures
on digital certificates using CA public key from their local
repository of trusted (CA) public keys).
This whole thing then goes to the root of improving the integrity of
the SSL domain name certificate infrastructure.
The catch-22 for the certification authority infrastructure is that if
they can start retrieving real-time public keys for authenticating
digital signatures on ssl domain name certificate applications
... then possibly the rest of the world could also start using DNSSEC
to also do real-time retrieval of onfile public keys from the domain
name infrastructure.
one might even imagine a highly optimized SSL type session protocol
where instead of the existing protocol chatter exchange ... the
servers on-file public key could piggyback on the standard DNS
response for hostname->ipaddress. the client in the initial
transmission send a random session key encrypted with the server's
public key.
a few recent posts mentioning this catch-22 dilemma for the SSL
domain name certificate industry:
https://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
https://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor
Status of opportunistic encryption
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of opportunistic encryption
Date: Fri, 02 Jun 2006 20:09:55 -0600
To: cryptography@xxxxxxxx
James A. Donald wrote:
In an organization with hundreds of administrators
managing tens of thousand of machines, what goes wrong
with trusting your key store? And who administers
Kerberos? Don't they have a problem with tens of
thousands of machines?
the original pk-init draft for kerberos just had public keys being
registered in lieu of passwords ... in much the same way that people
register public keys as part of the "registration authority" part of a
pki certification authority process.
https://www.garlic.com/~lynn/subpubkey.html#kerberos
machines then could have public keys to authenticate communicating
with the trusted public key store (imagine it like real-time access to
a certification authority ... in lieu of the stale, static digital
certificates). to the extent that such machines can trust a repository
of trusted certification authority public keys ... then they could
also have a trusted repository of public keys for real-time
communication with key store (where a key store might also be
replicated for availability and scaling ... in manner analogous to the
way DNS had replicated trusted servers).
https://www.garlic.com/~lynn/subpubkey.html#certless
it was only later that the draft succumbed to the pressure to also
allow PKI digital certificate mode of operation ... i.e. the machines
rather than doing real-time authenticated communication with the
trusted key store ... they might also use a local trusted public key
repository to authentication certification authority digital
signatures on stale, static digital certificates.
basically the key registration process is identical in the PKI digital
certificate mode of operation and the certificate-less public key mode
of operation. the management of the trusted public key repository (of
trusted "root keys" ... in one case for certification authorities, in
the other case for the key store) on each machine is effectively also
identical. however, the certificate-less public key mode uses real-time
communication with the key store ... while the PKI digital certificate
mode substitutes the whole digital certificate issuing, management,
administrative, etc infrastructure overhead (in lieu of the much
simpler real time communication).
Status of SRP
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Sat, 03 Jun 2006 07:01:57 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: cryptography@xxxxxxxx
Florian Weimer wrote:
FINREAD is really interesting. I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts. However, I fear that the
support costs are too high, and that's why it hasn't caught on in
retail online banking.
re:
https://www.garlic.com/~lynn/aadsm23.htm#45 Status of SRP
if they can build a $100 PC ... you think that they could build a
finread terminal for a couple bucks. sometimes there are issues with
volume pricing ... you price high because there isn't a volume and
there isn't a volume because you price high.
there is one issue missing from the actual FINREAD specification.
https://www.garlic.com/~lynn/subintegrity.html#finread
when we were doing X9.59 financial standard ... we allowed for a
digital signature for authentication as well as for a digital
signature from the environment that the transaction was performed
in. the issue from a relying party standpoint ... is what assurances
do they have as to the actual environment that a transaction was
executed in. consumers could claim they were using a FINREAD terminal
when they weren't. counterfeit FINREAD terminals could be out in the
wild.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
part of the x9.59 financial standard looked at the assurance/integrity
that a relying party might have with regard to the actual
authentication ... one factor, two factor, three factor ... and the
actual assurance/integrity of the associated factors (or conversely,
how vulnerable were the factors to compromise). this somewhat led into
also having to consider the assurance/integrity environment that the
authentication took place in (and what assurances would a relying
party have with regard to the environment).
part of it has been some past inclination to just specify some
standard ... w/o regard to how a relying party might actual have
assurances as to whether some standard or another was being followed
in an open environment (and considering threat scenarios that might
involve compromise/impersonation/counterfeit of various components).
for instance, there was a recent scenario in the UK where crooks were
impersonating maint. people and were updating secure POS terminals
with compromised components.
Status of SRP
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Sat, 03 Jun 2006 07:44:38 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
if they can build a $100 PC ... you think that they could build a
finread terminal for a couple bucks. sometimes there are issues with
volume pricing ... you price high because there isn't a volume and
there isn't a volume because you price high.
re:
https://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
another aspect was that there was a program in the past to give away
smartcards and card readers to consumers as part of doing smartcard
financial transactions. the issue at the time was that deployed
support for pc/sc standard only supported pc serial port interfaces
... and therefor the free card reader was a serial port device. there
was an ensuing disaster as consumers tried to get the serial port
device operational ... lots of stories of BSOD, having to re-install
everything from scratch, etc. as the dust was settling, there was a
quickly spreading opinion that smartcards (or at least smartcard
readers) were not viable in the consumer market segment. it was during
this period that m'soft even canceled its smartcard operating system
project.
recent post discussing the subject:
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
Status of opportunistic encryption
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of opportunistic encryption
Date: Mon, 05 Jun 2006 06:39:46 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
For DNS security to work at acceptable cost,
authentication has to be in band (perhaps the client is
more trusting of certificates signed by a root authority
that it has been seeing frequently for a long time,
supplemented ad hoc by whitelists and blacklists as the
need arises) and the certificates have to create only a
small additional overhead.
the only thing that makes a trusted root authority, a trusted root
authority is that the relying party has acquired the root authority's
public key out-of-band.
all the DNS clients in the world work out of band ... and have forever
... they are told (by the isp) what value to point DNS trusted
root(s) ... or are told to setup bootp/dhcp for a specific (supposedly
trusted) subnet ... and their ip-address, trusted dns setup, etc
... is supplied for them. one incremental change would be to
bootp/dhcp for the client to receive the trusted DNS public key at the
same time the client receives the trusted DNS ip-address. of course,
then bootp/dhcp represents the trusted root ... and then you might need
to add incremental security to the bootp/dhcp process.
the current issue is adding some sort of dynamic data authentication
mechanism to the current static values (like the ip-address)
... static values are well known for spoofing and replay attacks. the
current issue isn't that DNS doesn't currently have an enormous trust
infrastructure ... it is adding additional security and
countermeasures to various vulnerabilities
in-band trust processes have tended to be incremental ... the relying
party gets a token (like a public key) on initial contact. the relying
party remembers that token and the associated context. initially there
is little or no trust ... other than on each encounter that the
relying party is the same entity that they had delt with before. the
relying party keeps a knowledge base on encounters and develops trust
based on multiple encounters.
certificates that fit inside single UDP datagram was somewhat the x9
"compression" certificate standard ... trying to get a certificate on
the order of 300 bytes. basically it was throwing out all superfluous
and redundant information ... and/or anything that was already in the
financial institution's possession.
the issue in the mid-90s was that the financial institutions had
already realized that x.509 identity certificates for customers
represented enormous privacy and liability issues ... and had moved to
relying-party-only certificates ... basically only containing public
key, account number and all the CPS type gorp.
https://www.garlic.com/~lynn/subpubkey.html#rpo
the problem was that the typical payment transaction is on the order
of 60-80 bytes ... and the appended PKI overhead (even for relying-party-only certificates) was running 4k-12k bytes (two orders of
magnitude payload bloat ... i.e. 100 times payload bloat).
it was trivial to show that the account number was already in the
transaction payload ... and the customer's public key was already on
file at the financial institution (they had to register their public
key with their financial institution in order to have been issued the
relying-party-only certificate; note that registering their public key
was an out-of-band process).
as a result, it was possible to trivially demonstrate that the account
number and the public key could also be removed from the certificate.
after that, it was a trivial process to demonstrate that the rest of
the digital certificate could be compressed to zero bytes (by
comparison even a 300 byte, compressed certificate still represented a
payload bloat of five times for redundant and superfluous information)
by comparison, it was possible to show that digitally signed x9.59
financial standard transaction
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
with appended digital certificates compressed to zero bytes easily fit
within a UDP size datagram. compressed, zero byte digital certificates
was an alternative to shipping x9.59 w/o any appended certificates at
all
https://www.garlic.com/~lynn/subpubkey.html#certless
Status of opportunistic encryption
To: cryptography@xxxxxxxx
Subject: Re: Status of opportunistic encryption
Date: Mon, 05 Jun 2006 07:03:19 -0600
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
CC: James A. Donald <jamesd@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm23.htm#46 Status of opportunistic encryption
https://www.garlic.com/~lynn/aadsm23.htm#47 Status of opportunistic encryption
https://www.garlic.com/~lynn/aadsm23.htm#48 Status of opportunistic encryption
https://www.garlic.com/~lynn/aadsm23.htm#51 Status of opportunistic encryption
oh, and for bootp/dhcp information .... my rfc index
https://www.garlic.com/~lynn/rfcietff.htm
and click on Term (term->RFC#) in the RFCs listed by section.
select "BOOTP" and/or "DHCP" from the Acronym fastpath section
bootstrap protocol (BOOTP )
see also configuration , reverse address resolution protocol
2132 1542 1534 1533 1532 1497 1395 1084 1048 951
dynamic host configuration protocol (DHCP )
see also configuration , host , reverse address resolution protocol
4477 4436 4390 4388 4361 4332 4280 4243 4242 4174 4076 4039 4030 4014
3993 3942 3927 3925 3898 3825 3736 3679 3646 3634 3633 3594 3527 3495
3456 3442 3397 3396 3361 3319 3315 3256 3203 3118 3074 3046 3041 3011
3004 2939 2937 2855 2610 2563 2489 2485 2322 2242 2241 2132 2131 1541
1534 1533 1531
the index in "frame" mode has the RFC summaries in the lower frame.
clicking on any RFC number (in the Term->RFC# index), brings up that RFC
summary in the lower frame. clicking on the ".txt=nnn" field in the RFC
summary, retrieves that actual RFC.
possibly the two largest deployed authentication infrastructures are
Kerberos and Radius.
https://www.garlic.com/~lynn/subpubkey.html#kerberos
https://www.garlic.com/~lynn/subpubkey.html#radius
Both have done implementations where the client has registered a public
key and then authenticates using a digital signature, verified with the
onfile public key (in much the same way that digital signatures on
digital certificates are verified with onfile public keys of
certification authorities).
for broadband ISP users, the trust root typically just directly drops
into DHCP to obtain various internet configuration information supplied
by the ISP.
for dial-up users, the initial connection is PPP (long time ago it was
SLIP) where the client supplies a userid and some authentication
information that is validated from onfile information. then the
connection will move to DHCP for the rest of the configuration information.
point-to-point protocol (PPP )
4448 4334 4332 4058 3818 3817 3772 3770 3748 3627 3573 3545 3544
3518 3437 3373 3355 3353 3337 3336 3255 3241 3186 3153 3145 3079 3078
3070 3056 3032 3021 2878 2844 2835 2823 2759 2716 2701 2687 2686 2661
2637 2615 2516 2509 2507 2492 2491 2484 2472 2433 2420 2419 2364 2363
2290 2284 2153 2125 2118 2097 2043 2034 2023 1994 1993 1990 1989 1979
1978 1977 1976 1975 1974 1973 1969 1968 1967 1963 1962 1915 1877 1841
1764 1763 1762 1717 1663 1662 1661 1638 1619 1618 1598 1570 1552 1549
1548 1547 1474 1473 1472 1471 1378 1377 1376 1334 1333 1332 1331 1220
1172 1171 1134
remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
4372 4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809
2621 2620 2619 2618 2548 2139 2138 2059 2058
kerberos
see also authentication , generic security service , security
4430 4402 4121 4120 3962 3961 3244 3129 2942 2712 2623 1964 1510 1411
Status of SRP
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Tue, 06 Jun 2006 09:48:52 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: cryptography@xxxxxxxx
Florian Weimer wrote:
You mean something like remote attestation? I find it hard to
believe that this capability is available today in a relatively open
environment, on a platform supporting multiple applications
developed by different applications.
re:
https://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
https://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
i got involved in tracking down a virus/trojan like problem in the 70s
on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
basically if you are going to allow loading of stuff that can do its
own execution w/o many safeguards ... you are going to be extremely
vulnerable to numerous kinds of attacks.
either you have to very tightly control what applications are loaded
.... or possibly do a fixed function deployment that can support
multiple different applications ... possibly based on some form of
data driven architecture (i.e. the data specification possibly adapts
the functional operation to different applications w/o requiring
loading of executable code).
we had done the AADS chip strawman this way ... basically single
function operation w/o any ability to load executable code ... that
was adaptable to a large number of different applications
https://www.garlic.com/~lynn/x959.html#aads
another possible solution is very strong partitioning of any loadable
executable content that is allowed extremely limited/controlled
capability.
in the 60s as an undergraduate, i had done a lot with extremely
controlled partitioning ... which i learned much later got used in
various environments that had extremely high integrity requirements
... random drift
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
i had this discussion with the general manager of the business unit
that included java and java virtual machine (when it was in its very
early infancy) ... turns out that I had done some work with the person
(general manager) nearly 20 years earlier in a different life.
many of the modern generation of POS terminals are trying to cope with
this problem ... getting all sorts of frequent application downloads
of various kinds ... and still attempting to operate within
constraints of their trusted security module implementation.
basically if finread
https://www.garlic.com/~lynn/subintegrity.html#finread
is countermeasure to widely acceptable PC vulnerabilities (many that
arise because of the ease and common practice of loading executable
content) ... then if you deploy such a finread terminal that is
operated using similar conventions ... then it will acquire similar
vulnerability characteristics (as the environment that it is suppose
to be a countermeasure for).
Status of SRP
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Wed, 07 Jun 2006 05:39:35 -0600
To: cryptography@xxxxxxxx
James A. Donald wrote:
The concept of trusted computing is an attempt to
address this problem - each application has exclusive
access to certain data, a trusted path to interact with
the user, and the ability to prove to servers what code
is being executed on the client.
so they aren't exactly unrelated.
re:
https://www.garlic.com/~lynn/aadsm23.htm#45 Status of SRP
https://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
https://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
https://www.garlic.com/~lynn/aadsm23.htm#53 Status of SRP
the financial standards x9a10 working group had been given the
requirement to preserve the integrity for all retail payments. the
result was the x9.59 payment standards for all retail payments.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
part of x9.59 retail payment standard requires the transaction to be
authenticated. another part of the x9.59 retail payment standard
requires that the account number in x9.59 retail payments can't be
used in non-authenticated transactions. it as been recognized for a
long time that a major source of account financial fraud has been the
data breaches
https://www.garlic.com/~lynn/subintegrity.html#harvest
and resulting fraudulent use of account numbers ... this is somewhat
my old posting on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
in effect, account numbers have been overloaded. on one hand,
knowledge of account numbers have been sufficient for doing fraudulent
transactions. as a result they have to be treated as shared-secrets,
kept confidential and never divulged. on the other hand, account
numbers are required in a large number of business process as the
fundamental cornerstone for transaction execution ... and are required
to be widely available. as a result of these totally opposing
requirements, i've periodically observed that the planet could be
buried under miles of cryptography used in hiding account numbers, and
it would still be unable to prevent account number leakage. the
x9.59 business rule recognizes this and changes the paradigm,
eliminating the severe financial fraud vulnerability associated with
divulging account numbers (and/or data breaches involving account
numbers).
another part of x9.59, in addition to providing for transaction
digital signature as part of transaction authentication (and trying to
close some of the barn door with the overloaded requirements placed on
account numbers), was allowing for a second digital signature by the
environment (that the transaction originated in). this would provide
the relying party additional information for performing risk
assessment related to authorizing the transaction.
so later when this software company wanted to come up with something
for content providers, they hired the chair of the x9a10 financial
standards working group to move to redmond to be director of
development (which became the trusted computing effort you are
referring to)
for other drift on trusted computing ... there are capability based
operating systems ... current example is capros ... which was spawned
from eros, which was sort of spawned from keykos, which was spawned
from gnosis ... recent post mentioning some capros, eros, keykos,
gnosis, et all (and other related lore regarding secure and/or
capability-based operating systems ... going back to deployments by
commercial time-sharing service bureaus in the late 60s and their
connections to some of the current efforts ... as well as connections
to what i was doing as an undergraduate in the 60s)
https://www.garlic.com/~lynn/2006k.html#37
UK Detects Chip-And-PIN Security Flaw
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Subject: UK Detects Chip-And-PIN Security Flaw
Date: Wed, 07 Jun 2006 07:21:44 -0600
UK Detects Chip-And-PIN SecurityFlaw
http://www.cardtechnology.com/article.html?id=20060606I2K75YSX
APACS says the security lapse came to light in a recent study of the
authentication technology used in the UK's new "chip-and-PIN" card system.
... snip ...
this was documented as the yes card in 2002 regarding chip&pin
rollouts that had been done in the 99-2002 time-frame
since the yes card vulnerability is an attack against the pos
terminal (not the card) ... and since the vulnerability is part of the
standard ... even if all new cards were rolled with the "fix" ... the
infrastructure might still be vulnerable if POS terminals could be
convinced to communicate using the vulnerable standard (this is
somewhat analogous to protocol attacks and convincing parties to
downgrade to lower encryption).
yes card posts:
https://www.garlic.com/~lynn/subintegrity.html#yescard
man-in-the-middle attack posts
https://www.garlic.com/~lynn/subintegrity.html##mitmattack
misc. posts discussing the yes card vulnerability as well as
mentioning possible man-in-the-middle attack against the fix for yes
card vulnerability.
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
https://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
https://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
https://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
https://www.garlic.com/~lynn/2004j.html#39 Methods of payment
https://www.garlic.com/~lynn/2004j.html#44 Methods of payment
https://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006k.html#1 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006l.html#27 Google Architecture
UK Detects Chip-And-PIN Security Flaw
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: UK Detects Chip-And-PIN Security Flaw
Date: Wed, 07 Jun 2006 09:43:06 -0600
To: cryptography@xxxxxxxx
CC: jamesd@xxxxxxxx, fw@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
https://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/2006l.html#32 Google Architecture
as i mentioned, the x9a10 financial standards working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments .... this included at least all
kinds of internet, all kinds of POS, and all kinds of payments (debit,
credit, stored-value, etc).
part of the outcome of the resulting x9.59 financial standard was
transaction authentication. session authentication had been looked at,
and it was felt (compared to transaction authentication), that it was
much more vulnerable to end-point threats, mitm threats,
as well as insider threats.
from at least some retailers comments that chip&pin wasn't
appropriate for internet transactions ... it might be inferred that
chip&pin does session-like (as opposed to transaction)
authentication ... regardless of whether it is SDA or DDA (possibly
making it vulnerable to some of the end-point threats, mitm
threats, and/or insider threats considered by the x9a10
financial standard working group).
UK Detects Chip-And-PIN Security Flaw
http://www.cardtechnology.com/article.html?id=20060606I2K75YSX
using the x9.59 transaction authentication paradigm, i had started on
the aads chip strawman.
https://www.garlic.com/~lynn/x959.html#aads
at the NISSC conference in 98, i had quiped that I was going to take a
mil-spec security token, cost reduce it by two orders of magnitude
while increasing its security. from a chip&pin standpoint this met
having a chip doing (transaction) "DDA" at higher integrity than the
chip&pin DDA chip ... but at lower cost than the chip&pin SDA
chip. The aads chip strawman also needed to be able to do x9.59
transaction authentication within iso14443 contactless power profile
and within the transit industry turnstyle timing requirements.
tandem and atalla sponsored an x9.59/aads chip conference in jan. 1999
https://www.garlic.com/~lynn/aepay3.htm#riskm
later that spring, one of the aads conference participants
demonstrated aads strawman chip in their booth at the spring pc/world
conference in nyc doing a variety of financial and non-financial
transactions; including a AADS RADIUS implementation
https://www.garlic.com/~lynn/subpubkey.html#radius
recent posting mentioning RADIUS
https://www.garlic.com/~lynn/aadsm23.htm#52 Status of opportunistic encryption
a number of aads strawman chips were also demonstrated in dec. 1999 at
the world-wide retail banking show in miami, authenticating a variety
of different kinds of financial and non-financial transactions.
i gave a presentation on assurance at the 2001 intel developer's forum
(in the tpm track).
https://www.garlic.com/~lynn/index.html#presentation
I happened to quip during the presentation that it was nice to see
that the TPM chip design had started to look more and more like the
aads chip strawman over the previous year or so. the guy leading the
TPM chip effort was in the front row and quiped back that it was
because i didn't have a committee of 200 people helping me with my
design.
AADS Postings and Posting Index,
next, previous
- home