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, naïve use of TLS and/or tokens
- News and Views - Mozo, Elliptics, eBay + fraud, naïve use of TLS and/or tokens
- News and Views - Mozo, Elliptics, eBay + fraud, naïve 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
http://www.garlic.com/~lynn/aadsm12.htm#44 Identity Theft More Often an Inside Job
http://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
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)
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
http://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
http://www.garlic.com/~lynn/subpubkey.html#x959
http://www.garlic.com/~lynn/x959.html#x959
and aads
http://www.garlic.com/~lynn/x959.html#aads
starting in mid-90s, we called it parameterized 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). parameterized 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. parameterized risk management had the same online,
realtime infrastructure and real-time parameterized 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
parameterized 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 parameterized risk management is just
another application of Boyd for agile and adaptable operation.
misc. past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
misc. references to Boyd from around the web
http://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, naïve 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, naïve 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
http://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
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
News and Views - Mozo, Elliptics, eBay + fraud, naïve 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, naïve 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.
http://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)
http://www.garlic.com/~lynn/subpubkey.html#sslcert
News and Views - Mozo, Elliptics, eBay + fraud, naïve 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, naïve 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.
http://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
http://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:
http://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).
http://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
http://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm18.htm#50 link-layer encryptors for Ethernet?
http://www.garlic.com/~lynn/aadsm18.htm#51 link-layer encryptors for Ethernet?
http://www.garlic.com/~lynn/2002b.html#56 Computer Naming Conventions
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003i.html#62 Wireless security
http://www.garlic.com/~lynn/2004g.html#33 network history
http://www.garlic.com/~lynn/2004g.html#34 network history
http://www.garlic.com/~lynn/2004p.html#44 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#51 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#52 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005u.html#46 Channel Distances
http://www.garlic.com/~lynn/2005u.html#60 1970s data comms (UK)
http://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
http://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:
http://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
http://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:
http://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#7 PGP "master keys"
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://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.
http://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
http://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:
http://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#7 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#8 PGP "master keys"
http://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
http://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:
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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:
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/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:
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://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.
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://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:
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://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:
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#28 solving the wrong problem
http://www.garlic.com/~lynn/aadsm21.htm#10 Clearing sensitive in-memory data in perl
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#6 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#7 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client certificate for partner access
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/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
http://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:
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signature
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signature
http://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.
http://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.
http://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).
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signatures
http://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)
http://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
http://www.garlic.com/~lynn/x959.html#aads
and X9.59 work,
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://www.garlic.com/~lynn/subintegrity.html#mitm
or various kinds of other end-point vulnerabilities. some recent
postings on yes card technology
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views
http://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
http://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:
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin
misc. collected fraud, vulnerabilities, threats, exploit posts
http://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
http://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
http://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
http://www.garlic.com/~lynn/aadsm23.htm#16
http://www.garlic.com/~lynn/aadsm23.htm#17
a post in the original thread
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin
about chip&pin not being useable 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):
http://www.garlic.com/~lynn/subintegrity.html#harvest
or mitm-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm
recent posts
http://www.garlic.com/~lynn/aadsm23.htm#16
http://www.garlic.com/~lynn/aadsm23.htm#17
http://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)
http://www.garlic.com/~lynn/x959.html#x959
http://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:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#18 Security Soap Opera
http://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.
http://www.garlic.com/~lynn/subnetwork.html#hsdt
in the late 80s & early 90s were 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.
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
which is now comingly 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
http://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
http://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
Payment systems - the explosion of 1995 is happening in 2006
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):
http://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:
http://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
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
http://www.garlic.com/~lynn/aepay11.htm#42 Bank Float May Sink
http://www.garlic.com/~lynn/aadsm14.htm#7 Bank Float May Sink
http://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
http://www.garlic.com/~lynn/2005u.html#29 AMD to leave x86 behind?
http://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
http://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:
http://www.garlic.com/~lynn/aadsm23.htm#21 Reliable Connections Are Not
http://www.garlic.com/~lynn/2006i.html#16 blast from the past, reliable communication
http://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
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
http://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
http://www.garlic.com/~lynn/2001h.html#61
previous posts in this thread:
http://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch Chip&Pin
http://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch Chip&Pin
http://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends Chip&Pin
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends Chip&Pin
http://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
http://www.garlic.com/~lynn/aadsm23.htm#26 Petrol firms suspends chip-and-pin
and
http://www.garlic.com/~lynn/2001h.html#61
or parameterized risk management
http://www.garlic.com/~lynn/aadsm23.htm#1
note that the chip&pin counterfeit yes card chips mentioned in 2002 reference
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
and
http://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.
http://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.
http://www.garlic.com/~lynn/x959.html#x959
http://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 that there needed to be dynamic
data authentication that was not subject to skimming and replay
attacks.
http://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).
http://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:
http://www.garlic.com/~lynn/aadsm15.htm#21 Simple SSL/TLS - Some Questions
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/2005k.html#56 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://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:
http://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
http://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
http://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:
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#10 X.500, LDAP Considered harmful Was: OCSP/LDAP
http://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server
http://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#5 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#27 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
http://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm19.htm#40 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2003g.html#47 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
http://www.garlic.com/~lynn/2004g.html#5 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
http://www.garlic.com/~lynn/2004m.html#23 Help! I'm trying to understand PKI - especially CA's role
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#38 xml-security vs. native security
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#45 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005h.html#25 couple more Q's on basic public key encryption techniques
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
http://www.garlic.com/~lynn/2005i.html#4 Authentication - Server Challenge
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
http://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
http://www.garlic.com/~lynn/2006e.html#42 SSL Certificate Signing
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
http://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
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
and
http://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 m