Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
previous
- home
- H6.2 Most Standardised Security Protocols are Too Heavy
- H6.2 Most Standardised Security Protocols are Too Heavy
- Threatwatch: Still searching for the economic MITM
- Solution to phishing -- an idea who's time has come?
- Public key encrypt-then-sign or sign-then-encrypt?
- Leadership, the very definition of fraud, and the court of security ideas
- Leadership, the very definition of fraud, and the court of security ideas
- Solution to phishing -- an idea who's time has come?
- Leadership, the very definition of fraud, and the court of security ideas
- Enterprise Right Management vs. Traditional Encryption Tools
- K6 again, again and again. Therefore, H6.4 -- Compromise on Security before Delivery
- Is this Risk Management's Waterloo?
- 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
- Is this Risk Management's Waterloo?
- 307 digit number factored
- 307 digit number factored
- dnssec?
- dnssec?
- PKI moving to adopt the plugin model -- realignment to security based on user-needs?
- 307 digit number factored
- 307 digit number factored
- 307 digit number factored
- A crazy thought?
- Identity resurges as a debate topic
- Why self describing data formats:
- Why self describing data formats:
- A crazy thought?
- A crazy thought?
- A crazy thought?
- A secure Internet requires a secure network protocol
- A secure Internet requires a secure network protocol
- The bank fraud blame game
- The bank fraud blame game
- The bank fraud blame game
- The bank fraud blame game
- The bank fraud blame game
- TPM, part 2
- The bank fraud blame game
- The bank fraud blame game
- a fraud is a sale, Re: The bank fraud blame game
- a fraud is a sale, Re: The bank fraud blame game
- The bank fraud blame game
- The bank fraud blame game
- a fraud is a sale, Re: The bank fraud blame game
- Threatwatch: how much to MITM, how quickly, how much lost
- Threatwatch: how much to MITM, how quickly, how much lost
- Threatwatch: how much to MITM, how quickly, how much lost
- If your CSO lacks an MBA, fire one of you
- If your CSO lacks an MBA, fire one of you
- If your CSO lacks an MBA, fire one of you
- If your CSO lacks an MBA, fire one of you
- Know Your Enemy: Scott McNeally on security theater
- more on firing your MBA-less CSO
- Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"
- Security can only be message-based?
- Microsoft asserts itself as an uber-CA
- The Uneasy Ride on the Cryptography Bandwaggon
- The fundamental _barrier to entry_ in the business of payment systems
- On the downside of the MBA-equiped CSO
- Threatwatch - more data on cost of your identity
- Retailers try to push data responsibilities back to banks
- Linus: Security is "people wanking around with their opinions"
- Fingerprint Firefox Plugin?
- Oddly good news week: Google announces a Caps library for Javascript
- How to crack RSA
- MITM spotted in Tor
- 2007: year in review
H6.2 Most Standardised Security Protocols are Too Heavy
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2007 10:14 AM
Subject: H6.2 Most Standardised Security Protocols are Too Heavy
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000912.html
these posts mention being called in to consult with small
client/server startup that wanted to do payments on their server
... and they had this technology called SSL.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
some of the work for deployment including doing some of the stuff for
taking a technology and turning it into a business process. this is
now frequently called electronic commerce and is probably the main use
of SSL in the world today.
misc. other posts about the business process related to the digital
certificates for the SSL process
https://www.garlic.com/~lynn/subpubkey.html#sslcert
i've mentioned before that we subsequently worked on x9.59 financial
transaction protocol
https://www.garlic.com/~lynn/x959.html#x959
which can be considered to obsolete much of the work that we had
previously done in conjunction with SSL (for what is commonly now
called electronic commerce). recent post here
https://www.garlic.com/~lynn/aadsm26.htm#70 WSJ: Soft evidence on a crypto-related breach
Now this recent post makes some slight reference to issues with using
a connection protocol for transaction operation
https://www.garlic.com/~lynn/2007j.html#38 Problem with TCP connection close
... for some minor historical drift ... while tcp/ip is the technology
basis for the modern internet, we claim that the operational basis for
the modern internet came with the NSFNET backbone. Here is some old
collected email working on various aspects of NSFNET backbone ... and
then not being allowed to bid (even tho subsequent NSF audit of what
we already had running claimed that it was at least five yrs ahead of
all NSFNET backbone bids to build something new):
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
we also served on what was the "XTP" technical advisory board
... attempting to do both high-speed protocol as well as support
reliable transactions. The above post references that session TCP
operation requires a minimum of seven packet exchange ... and that
VMTP/RFC1045 required minimum of five packet exchange. XTP only needed
a minimum of three packet exchange for reliable transaction operation.
misc. posts mentioning XTP as well as folly of attempting to get an
XTP high-speed protocol work item into ISO standards ... where ISO
network standards had a requirement that only work on network
standards could be done for things that don't violate OSI model (and
turns out that both IP, internetworking protocol and LAN/MACs violate
OSI).
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
now these series of posts mention that general internet public key
distribution could be done as part of DNSSEC that includes registering
public keys with DNS as part of domain name registration. The basic
objective improves the integrity of DNS ... which the SSL domain name
certification authorities rely on when they are attempting to validate
SSL digital certificate applications. However, it could also be used
to obsolete the need to have SSL digital certificates for public key
distribution (doing real-time, online, trusted distribution)
... creating something of a catch-22 for the certification authority
industry
https://www.garlic.com/~lynn/subpubkey.html#catch22
If registered public key could be piggy-backed on the standard DNS
domain to ip-address response (along with any required crypto
preferences) ... then the client would have the server's public key
before even contacting the server (w/o any additional protocol
chatter). for other topic drift some old crypto related email
https://www.garlic.com/~lynn/lhwemail.html#crypto
including one from may81 about a proposal for online network service
for trusted public key distribution
https://www.garlic.com/~lynn/2006w.html#email810515
Coupled with XTP, an extremely simplified, transaction SSL is possible
... a client could generate a random secret key, encrypt transaction
message with the secret key, encrypt the secret key with the server's
public key ... and send the combination (encrypted transaction message
and encrypted secret key) to the server in a single message
This is separate from the x9.59 transaction scenario with regard to
whether it is necessary to hide/encrypt the information at all; x9.59
transaction could be sent via XTP to a server w/o requirement for
hiding/encryption.
H6.2 Most Standardised Security Protocols are Too Heavy
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2007 11:42 AM
Subject: H6.2 Most Standardised Security Protocols are Too Heavy
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardized Security Protocols are Too Heavy
for a little additional topic drift ....
in the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for *ALL* retail payments ... which results in x9.59
financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959
there were various other efforts going on in the area of secure
payment protocols at the time ... attempting to improve what had
already been done for electronic commerce with SSL
typical of the genre from the period ... there were protocols proposed
that would increase the payload of typical payment transaction by a
factor of 100 times (enormous payload bloat) as well as processing by
a factor of 100 times (enormous processing bloat) ... misc. past posts
mentioning some of the activity from the period that would result in
enormous bloat
https://www.garlic.com/~lynn/subpubkey.html#bloat
Threatwatch: Still searching for the economic MITM
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2007 03:08 PM
Subject: Threatwatch: Still searching for the economic MITM
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000913.html
one of the issues is that the professional attackers, in it for the
money ... don't divulge anything ... or go around advertising ... not
like the kids that frequently are after the bragging rights.
a lot of the defenders ... when they do find a serious attack ... seem
to be quite motivated not to advertise it also.
this is one of the issues behind the early cal. security breach
notification legislation ... that institutions weren't making it
public ... even after they found out about it.
when we were called into help word-smith the cal. electronic signature
legislation ...
https://www.garlic.com/~lynn/subpubkey.html#signature
we also happen to observe some of the stuff going on around the
disclosure legislation. Since then, federal legislation has been
see-sawing back and forth between something the equivalent of the
cal. state legislation and a federal "pre-emption" bill (nullifying
state statutes) more along the lines of some of the "CAN-SPAM"
characteristics.
some recent posts mentioning the subject:
https://www.garlic.com/~lynn/2007f.html#72 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#55 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007i.html#40 Best practices for software delivery
https://www.garlic.com/~lynn/2007i.html#58 John W. Backus, 82, Fortran developer, dies
other posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
many of the public wireless operations ... have bootp/dhcp setup for
client configuration (DNS server, ip-gateway, ip-address, etc) for
initial contact that directs all the client's traffic to a special
server ... which pre-empts everything until some sort of
authentication is performed.
After the initial authentication ... then the client will get normal
configuration update for standard internet operation, DNS server,
ip-gateway, etc.
So are we talking about an attacker being able to force standard
internet operation configuration (DNS server, ip-gateway, etc) w/o
having to first authenticate handshake with the initial server?
Other attacks can be more serious attempting to harvest information
(evesdropping, mitm reroute, etc) that can be used in replay attacks
(userid/passwords, account numbers, etc).
minor recent news item
Cyber-thieves 'richer than drug dealers'
http://www.computing.co.uk/vnunet/news/2189322/cyber-thieves-richer-drug
Cyber-thieves 'richer than drug dealers'
http://www.vnunet.com/vnunet/news/2189322/cyber-thieves-richer-drug
which somewhat compliments some past articles about cyber crime now
involving more money than drug crime.
Solution to phishing -- an idea who's time has come?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 9, 2007 09:15 AM
Subject: Solution to phishing -- an idea who's time has come?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000914.html
periodic recent comments that (in the current infrastructure/paradigm
where replay attacks are so easy) attackers can afford to outspend
defenders ... possibly as by as much as 100:1.
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
and old standby post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
the real weakness is in the trivial ease that attacker can use the
harvested information for financial gain ... trying to plug the holes
in the ability of harvesting the information is like plugging holes in
dike made of swiss cheese. what needs to be done is changing the
paradigm so the holes are plugged in the ease that attackers are able
to use the information for financial gain.
this is related to the frequent past observation that even if the
planet was buried under miles of encryption ... it still won't prevent
information leakage. misc. refs:
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
Public key encrypt-then-sign or sign-then-encrypt?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Public key encrypt-then-sign or sign-then-encrypt?
Date: Wed, 09 May 2007 13:54:16 -0600
To: cryptography@xxxxxxxx
Travis H. wrote:
This reminds me a bit of a suggestion I once heard for protocol
designers that the messages of the various steps of the protocol
include a step number or something like it to prevent cut-and-paste
attacks (presumably each message has some redundancy to protect the
integrity/authenticity as well, like a running hash covering all the
previous messages (in this direction)).
I wonder if something similar couldn't be done with digital
signatures, where the input is padded with data that indicates the
semantics of the signature; not unlike the forms which say "by signing
here I agree that..."
This also makes it very difficult for the opponent to do any kind
of chosen-plaintext trickery since the plaintext will be framed
with this data that the opponent does not control, but that is
also true with other padding options and such.
re:
https://www.garlic.com/~lynn/aadsm26.htm#65 Public key encrypt-then-sign or sign-then-encrypt?
some aspects of this was discussed in old dual-use attack thread
... it possibly isn't enuf to encapsulate all scenarios where the
person intends to use the digital signature in manner analogous to
human signature (indicating intent, having read, understood,
agrees, approves, and/or authorizes) .... then if there is ever a
digital signature applied for pure authentication purposes ... say
random data from a server (as countermeasure to replay attacks)
... then all such signed data should always also be bracketed by
disclaimer saying that such signatures are in no way met to imply
agreeing, approving, and/or authorization any message content.
the problem is that digital signatures are an authentication and
integrity mechanism, and except for possible semantic confusion
resulting from both "digital signature" and "human signature"
containing the same word ("signature") ... there is no relationship. a
danger of any mis-use of digital signatures as representing human
signatures ... is if they are also used for authentication ... where
the human doesn't actually physically examine and understand every bit
that a signature might be applied to. if the human doesn't actually
physical examine and understand every bit that they might apply a
signature too ... then it becomes a requirement that all such (signed
and unexamined) bits are wrapped with strong disclaimer about any
existence of a digital signature is NOT met to imply read,
understood, agrees, approves, and/or authorizes.
... aka any random data not examined, but signed ... could in fact
contain padding and comments about aggreement ... to appear as if the
signer actually wrapped it (instead of the attacker).
lots of past posts discussing "signatures" ... included having been
called in to help word-smith the cal. state electronic signature
legislation.
https://www.garlic.com/~lynn/subpubkey.html#signature
related and slightly facetious posting here:
https://www.garlic.com/~lynn/aadsm26.htm#69 survey of RFC S/MIME signature handling
as part of this thread
https://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature handling
Leadership, the very definition of fraud, and the court of security ideas
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2007 11:09 AM
Subject: Leadership, the very definition of fraud, and the court of security ideas
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000915.html
minor topic drift in sci.crypt ng ... the thread was "open source
voting" ... but the response was to some comments about financial
industry having standards and standards bodies (this is before current
state where sci.crypt is being bombed by somebody ... all the posts
are really coming from the same id if you look at the hdrs)
https://www.garlic.com/~lynn/2007j.html#67 open source voting
Leadership, the very definition of fraud, and the court of security ideas
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2007 02:20 PM
Subject: Leadership, the very definition of fraud, and the court of security ideas
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/2007j.html#67 open source voting
https://www.garlic.com/~lynn/aadsm27.htm#5 Leadership, the very definition of fraud, and the court of security ideas
aka the original post appeared to assert that the reason that the
financial industry had "open" security standards was because that the
standards were "open" to lots of people looking at them ... and
potentially with all the examination, would result in identifying
deficiencies and result in overall better security.
an alternative possible explanation was that in a dispute or
litigation ... showing that there was conformance to (some) accepted
standards ... reduced what needed to be established/proven (from
scratch) in resolving the dispute ... aka the use of standards is a
(at least partial) defense.
better defense (in litigation) and better security are not necessarily
identical.
Solution to phishing -- an idea who's time has come?
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2007 11:39 PM
Subject: Solution to phishing -- an idea who's time has come?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
a little topic drift ....
EU banks in secret debit card talks: document
http://biz.yahoo.com/rb/070511/banks_payments_eu.html?.v=1
EU banks in secret debit card talks
http://business.scotsman.com/latest.cfm?id=730292007
EU lawmakers back cheaper cross-border payments
http://www.neurope.eu/view_news.php?id=73543
JCC at crossroads to the future
http://www.financialmirror.com/more_news.php?id=6732&type=st&nt=Business
Payment Services Directive pushed through by Parliament
http://www.euractiv.com/en/financial-services/parliament-waives-payment-services-directive/article-163368
European Business Guide: Payment Services Directive: Parliament adopts the proposal
http://www.businessupdated.com/shownews.asp?news_id=2391&cat=Payment+Services+Directive:+Parliament+adopts+the+proposal
and for something a little different:
Hacking Citibank's Virtual Keyboard
http://news.yahoo.com/s/zd/20070511/tc_zd/207329
it does mention that the virtual keyboard is designed as a
countermeasure to a hacked machine possibly having a keylogger ... and
that this exploit is from 2005 (aka a different kind of keylogger
variation) ... although it may actually go back a decade.
aka from
Defeating Citi-Bank Virtual Keyboard Protection
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=17684
however, the above URL from 8aug05 doesn't get the original article
... but a current reference.
Leadership, the very definition of fraud, and the court of security ideas
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 12, 2007 11:28 AM
Subject: Leadership, the very definition of fraud, and the court of security ideas
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#5 Leadership, the very definition of fraud, and the court of security ideas
https://www.garlic.com/~lynn/aadsm27.htm#6 Leadership, the very definition of fraud, and the court of security ideas
the other part is that a lot of the industry is point-solution
wonderkind patches ... that don't actually correct any problem but
create a paradigm of life-long patches.
https://www.garlic.com/~lynn/2007j.html#67 open source voting
this somewhat tempts to stray into the subject nothing succeeds like
failure ... referenced here:
https://www.garlic.com/~lynn/aadsm26.htm#59 On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?
and misc. post postings making reference to (problems with) security
point-solution (patches)
https://www.garlic.com/~lynn/2005t.html#25 Why does my address appear as part of my name?
https://www.garlic.com/~lynn/2007e.html#12 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#66 John W. Backus, 82, Fortran developer, dies
Enterprise Right Management vs. Traditional Encryption Tools
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Enterprise Right Management vs. Traditional Encryption Tools
Date: Mon, 14 May 2007 11:46:55 -0600
To: Jason Holt <jason@xxxxxxxx>
CC: Ali, Saqib <docbook.xml@xxxxxxxx>, Jon Callas <jon@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>, FDE@xxxxxxxx
Jason Holt wrote:
ERM/DRM/TPM are such poorly defined and implemented products that
people have started referring to a "DRM fairy" who people assume
will wave her wand and solve whatever problem is at hand. I used to
try to draw out the mentioner's claims into a concrete proposal that
everyone could objectively examine, but the conversation rarely
progressed that far. So now I think that, as with other crypto
proposals, the onus should now be on the proposer to clearly
delineate what they're proposing and convince us that it's complete
and correct, rather than us nodding our heads or lashing out at what
we assume it means.
somewhat aside ... there was an effort in the very early days of the
PC to look at (hardware) countermeasures to software (and other)
piracy (I don't remember whether i was involved shortly before or
after the actual announcement of the PC).
starting with 370, the mainframes had unique processor identifications
and licensed software was configured for the specific processor. this
may have been relatively easy to defeat ... but the numbers and costs
involved somewhat created a barrier. It was sufficient to show that
some (illegal) action had to have been taken in order to successfully
prosecute.
because the costs and numbers involved with the PC were so
significantly different, individual prosecution was harder to justify
... and so the hardware countermeasures needed to be much more
robust. a problem with the investigation at the time was that
tamper-evident technologies were way too expensive which contributed
to the investigation being shelved.
somewhat in the wake of that ... there were various methods like
specially encoded floppy disks as countermeasure to piracy (i.e. the
floppy disks were not trivially duplicated by normal means).
K6 again, again and again. Therefore, H6.4 -- Compromise on Security before Delivery
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 15, 2007 09:39 AM
Subject: K6 again, again and again. Therefore, H6.4 -- Compromise on Security before Delivery
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000919.html
I was once at a monthly meeting where somebody talked about security
evaluations (the old C2, B2, A2, etc type stuff and the newer
replacement, common criteria and protection profiles). supposedly a
purpose of the security evaluations would be to allow customers to
make some comparable security assessment about different security
products from different vendors.
One of the comments was that there had been something like 64 common
criteria evaluations of particular types of product and of the 64, 62
evaluations had some sort of unpublished deviations and/or exceptions
(devaluing the usefulness of security comparisons).
Is this Risk Management's Waterloo?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 18, 2007 11:37 AM
Subject: Is this Risk Management's Waterloo?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000922.html
old, long winded post about the thread between risk management and
information security
https://www.garlic.com/~lynn/aepay3.htm#riskm
for little side track ... risk management is more than security issues
... "insurance" traditionally is part of a risk management toolkit and
used for things far from traditional security issues. for other issues
see BIS and BASEL
http://www.bis.org/publ/bcbsca.htm
in the past, i've hypothesized that there have been instances where a
risk adverse organization has avoided addressing a problem (say ISP
with regard to incoming/ingress from their customers ... filtering
long before it got to the destination end) since they might then be
held accountable if the measures weren't perfect (and then got
sued). They sidestepped liability by doing nothing (at least until
some sort of gov. authority steps in and mandates something)
some of these scenarios is that not doing something might put their
customers at risk ... but wouldn't directly affect the
institutions. doing something that turned out to be not one hundred
percent perfect created more risk and liability to the institution
than doing nothing.
this old post is about security (aka countermeasures) proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
where the value to the attacker is several times larger than the value
to the defender ... and is somewhat related to the whole "naked
transaction" discussion
https://www.garlic.com/~lynn/subintegrity.html#payments
from a slightly different perspective
https://www.garlic.com/~lynn/2007k.html#12
https://www.garlic.com/~lynn/2007k.html#13
i also had these discussions/arguments in the early & mid 90s about
ISPs being able to just about eliminate IP-address spoofing and DOS
attacks with ingress filtering (this was before botnets and DDOS
attacks).
when we were working on the financial industry privacy standard
(including some of the disclosure issues), we made the comment that it
was going to require some culture change for institutional risk and
security professionals. traditionally, institutional risk & security
professionals were looking at protection of the institution. various
gov. mandates were forcing institutional risk & security professionals
to start thinking about protecting the institution's customers (in
some of the scenarios even protecting the customers from the
institution).
0wned .gov machines (was Re: Russian cyberwar against Estonia?)
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
Date: Sun, 20 May 2007 09:03:08 -0600
To: Ivan Krstić <krstic@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>,
Trei, Peter <ptrei@xxxxxxxx>, cryptography@xxxxxxxx
Ivan Krstić wrote:
I think it's anything but surprising. There's only so much you can do to
significantly improve systems security if you're unwilling to break
backwards compatibility -- many of the fundamental premises of desktop
security are fatally flawed, chief among them the idea that all programs
execute with the full privileges of the executing user.
part of this is that many of the basic platforms providing internet
connectivity evolved from disconnected/unconnected desk/table top
environment ... with lots of applications assuming that they had full
& free access to all resources.
attempting to leverage the same platforms for connectivity to
extremely hostility and anarchy of the internet creates diametrically
opposing requirements.
one countermeasure from the 60s is to use a dynamically created
("padded cell") virtual machine for internet connectivity ... with
limited scope and accesses. then when the session completes ... the
environment is collapsed and everything is discarded.
while the "native" system operation may have little or no defenses
against the hostile internet ... the "padded cell" virtual machine
environment is used to bound the scope of any penetration ... somewhat
analogous to "air gapping".
recent post:
https://www.garlic.com/~lynn/2007k.html#48
somewhat older reference:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
Is this Risk Management's Waterloo?
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 20, 2007 11:27 AM
Subject: Is this Risk Management's Waterloo?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#11 Is this Risk Management's Waterloo?
i.e. insurance, alarms, bumpers, guard rails, etc are all types of
risk management
possibility is that with regard to information systems, very few
people have any fundamental understanding of related threats,
vulnerabilities, etc. ... i.e. w/o any fundamental understanding how
information systems operate ... any treat and vulnerability analysis
will miss enormous number of issues.
for slightly related topic drift
https://www.garlic.com/~lynn/aadsm27.htm#12 Owned .gov machines (was Re: Russian cyberwar against Estonia?)
the above is specific with regard to implementations that evolved from
a non-hostile and disconnected environment with few or little
countermeasures.
now some of the more systems that are considered quite a bit more
secure 1) have been implemented in languages other than "C" and are
remarkably free of the buffer overrun/overflow types of exploits and
2) originally assumed a potentially hostile environment and so risk
mitigation permeates all aspects of design and implementation.
for other drift ... my work on merged taxonomies and glossaries
https://www.garlic.com/~lynn/index.html#glosnote
I've drawn on numerous sources for merged security taxonomy and glossary
https://www.garlic.com/~lynn/secure.htm
click on "risk management" in the glossary "fastpath" and there are
broad range of definitions ... some specific to information systems
and others more general.
from GAO 06-91:
A continuous process of managing through a series of mitigating
actions that permeate an entity's activities, the likelihood of an
adverse event and its negative impact. Risk management addresses risk
before mitigating action, as well as the risk that remains after
countermeasures have been taken.
... snip ...
307 digit number factored
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 307 digit number factored
Date: Mon, 21 May 2007 20:48:19 -0600
To: cryptography@xxxxxxxx
Victor Duchovni wrote:
The other issue is that sites will need multiple certs during any
transition from RSA to ECC, because the entire Internet won't upgrade
overnight. I am not expecting public CAs to cooperate by charging the
same price for two certs (RSA and ECC) for the same subject name(s),
this also may significantly impede migration.
in theory, certification authorities charge for the certification
operations that they perform ... and the certificate is just a
representation of that certification process.
somewhere over the yrs the term "certification authority" was
truncated to "certificate authority" ... along with some impression
that certificates are being sold (as opposed to certification
processes).
doing quicky web search of licensing and certification agencies ... it
looks like there is charge for replacing certificates/licenses ... but
nothing compared to the charge for the original certification process.
of course ... the whole licenses/credentials/certificates are an
offline world paradigm .... licensing, credentialing, and
certifications can be validated with online, real-time operations
... obsoleting any requirement for supporting offline methodologies.
it would be really great to make it an excuse to move away from
offline paradigm to real online operation ... getting totally rid of
the need for domain name certificates ... DNS serving up both
ip-addresses and public keys in single operation.
307 digit number factored
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 307 digit number factored
Date: Tue, 22 May 2007 09:40:29 -0600
To: Ivan Krstić <krstic@xxxxxxxx>
CC: cryptography@xxxxxxxx
Ivan Krstić wrote:
That can't happen until we make sure you can trust DNS, which in turn
can't happen until we get a concrete proposal that has clearly defined
goals and isn't braindead. As has been amply pointed out, it's not clear
that DNSSEC will cut it anytime soon.
re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
A big part of the issue is the domain name certification authority has
to trust the domain name infrastructure as to the true owner of the
domain name ... when they are processing a domain name certificate
application for certification (i.e. only the actual domain name owner
on file with the domain name infrastructure should be able to apply
for domain name certifications).
The catch-22 is that the original idea behind domain name certificates
were because of integrity issues with the domain name
infrastructure. However, the domain name certification industry is
dependent on the integrity of the domain name infrastructure in their
domain name certification process.
As a result they need to improve the integrity of the domain name
infrastructure because their dependency on the domain name
infrastructure in their process of certification.
So one of the proposals (somewhat backed by the domain name
certification authority industry) is that domain name owners place a
public key on file when they register a domain name with the domain
name infrastructure. They all future communication with the domain
name infrastructure can be digitally signed ... and the domain name
infrastructure verifies the digital signature with the onfile public
key.
This is intended to help improve the integrity of the domain name
infrastructure. However, it could also offer benefits to the domain
name certification authority industry. The domain name certification
authority industry could also then start requiring that domain name
certification applications also be digitally signed. The the domain
name certification authority industry can do a real-time retrieval of
the on-file public key to verify the domain name certification
application digital signatures. This provides for turning a
time-consuming, error-prone, and expensive identification process into
a much simpler, reliable, and less expensive authentication process
(enormous benefits for the domain name certification authority
industry).
The issues for the domain name certification authority industry
are somewhat two fold:
1) the original justification for domain name certification involved
integrity issues with the domain name infrastructure. improving the
integrity of the domain name infrastructure would reduce the original
justification for having domain name certification
2) if the domain name certification authority industry could start
relying on real-time retrieval of public keys ... then possibly the
rest of the world could also ... eliminating the need for domain name
certifications
some collected catch-22 posts
https://www.garlic.com/~lynn/subpubkey.html#catch22
long ago and far away, we had been called in to consult with this
small client/server startup that wanted to do payment transactions and
had this technology called SSL. In addition to doing stuff about
working out the payment transaction operation we also had to do a lot
of stuff with end-to-end business process investigation of these new
business operations called certification authorities. Since then, this
has frequently come to be referred to as electronic commerce. some old
posts
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
and collection of posts mentioning payment processing and payment
gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway
Now, the original SSL infrastructure was to verify that the URL that
the user entered (into the browser) corresponded to the website that
the browser was talking to (i.e. the website that the user thought
they were talking to was the website they were actually talking
to). However, most electronic commerce sites fairly quickly found that
SSL was costing them something like 90percent of their thruput. The
result was that most websites transitioned to no longer using SSL for
the initial user connection but reserved just for the payment process
(to hide the account number information). Now the user clicks on a
button (provided by the webserver) which generates a URL (provided by
the webserver). Now instead of checking the URL provided by the user
against the webserver ... most use of SSL now checks the URL provided
by the webserver against the webserver (invalidating the original SSL
security assumptions). lots of past posts about ssl digital
certificate infrastructure
https://www.garlic.com/~lynn/subpubkey.html#sslcert
so it could be claimed that the way that the currently deployed SSL
for the electronic commerce infrastructure doesn't really cut it
either ... it is somewhat a case of the emperor's new clothes ... and
the integrity of the domain name infrastructure has to be improved in
any case, since it is the trust root for the whole domain name
certification authority industry's certification process (but fixing
the integrity of the trust root could also make additional domain name
certification processes redundant and superfluous).
afterwards we did some work with the x9a10 financial standard working
group that in the mid-90s had been given the requirement to preserve
the integrity of the financial infrastructure for all retail payments
(i.e. all, point-of-sale, internet, credit, debit, ach, face-to-face,
stored-value, aka ALL). The result was the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
In the security acronym "PAIN"
- P ... privacy (or sometimes CAIN, confidential)
- A ... authentication
- I ... identification
- N ... non-repudiation
now, we've claimed that possibly the largest use of SSL is in support
of electronic commerce (to hide account number information).
however, in X9A10, a detailed end-to-end vulnerability and threat
analysis was performed ... and divulging account information was
identified as major exploit (requiring SSL to hide transaction
information). However the majority of exploits had never been
capturing information in transit (before SSL, even before the
internet) ... it had always been capturing information at end-points
and/or logs of previous transactions. As a result, a primary objective
of X9.59 financial standard was to eliminate havesting/skimming of
previous transactions as a (replay attack) vulnerability. The
result was that X9.59 effectively "armors" every transaction ... in
effect replaces "privacy/confidentiality" as a countermeasure
with "authentication" and "integrity".
X9.59 transactions no longer have to be hidden as a fraud
countermeasure. This eliminates the requirement to hide such
transactions ... and therefor eliminates the major use of SSL in the
world today (related to electronic commerce). X9.59 also eliminates
the major threats and vulnerabilities related to the data
breaches and security breaches that have been in the news
recently. some related recent posts about naked transactions/payments
metaphor
https://www.garlic.com/~lynn/subintegrity.html#payments
for some topic drift ... lots of the stuff being "hidden" with SSL are
really transaction oriented operations ... and if domain name
infrastructure could serve up public keys ... there could be
significant thruput improvements in such protocols. some recent posts
in a financial crypto blog
https://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardized Security Protocols are Too Heavy
https://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardized Security Protocols are Too Heavy
dnssec?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: dnssec?
Date: Tue, 22 May 2007 14:31:06 -0600
To: cryptography@metzdowd.com <cryptography@metzdowd.com>
re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
sometimes i wonder if at least some of the dnssec issue doesn't turn
out to be related to not having a revenue flow champion.
domain name certification business caught on fairly rapidly (as
countermeasure to perceived integrity issues with domain name
infrastructure).
fixing the domain name infrastructure integrity issues 1) doesn't
appear to have any champion (at least motivated with significant
incremental revenue flow) ... and 2) could make the existing industry
doing domain name certifications obsolete, redundant and superfluous.
for other topic drift ... a recent post with some DNS related trivia
... more than a decade before DNS (about half-way down the post
mentioning former MIT student)
https://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX
and for other topic drift, old email about online, real-time public
key distribution (also predating DNS)
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
dnssec?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: dnssec?
Date: Wed, 23 May 2007 13:52:23 -0600
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
Anne & Lynn Wheeler wrote:
for other topic drift ... a recent post with some DNS related trivia ...
more than a decade before DNS (about half-way down the post mentioning former
MIT student)
https://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX
and for other topic drift, old email about online, real-time public key
distribution (also predating DNS)
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
and rfc editor announcement from today .... my rfc index
https://www.garlic.com/~lynn/rfcietff.htm
https://www.garlic.com/~lynn/rfcidx8.htm#4871
4871 PS
DomainKeys Identified Mail (DKIM) Signatures, Allman E., Callas J.,
Delany M., Fenton J., Libbey M., Thomas M., 2007/05/22 (71pp)
(.txt=166054) (Obsoletes 4870) (See Also 4870) (Refs 1847, 2045, 2047,
2440, 2821, 2822, 3447, 3490, 3766, 3833, 3851, 4033, 4234, 4686) (was
draft-ietf-dkim-base-10.txt)
https://www.garlic.com/~lynn/rfcidx8.htm#4870
4870 -H
Domain-Based Email Authentication Using Public Keys Advertised in
the DNS (DomainKeys), Delany M., 2007/05/22 (41pp) (.txt=87378)
(Obsoleted by 4871) (See Also 4871) (Refs 1421, 3833, 3851, 4648) (was
draft-delany-domainkeys-base-06.txt)
PKI moving to adopt the plugin model -- realignment to security based on user-needs?
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 23, 2007 06:03 PM
Subject: PKI moving to adopt the plugin model -- realignment to security based on user-needs?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000927.html
or make it obsolete, redundant and superfluous
recent thread/posts in crypto mailing list
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
including reference to brand new RFC for fixing spam and phishing
(using DNS to serve up public keys)
New antiphishing, antispam specifications unveiled
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9020940
IETF approves new weapon to fight spam, phish
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1256125,00.html
and for slight drift ... sort of DNS related trivia reference more
than a decade before DNS
https://www.garlic.com/~lynn/2007k.html#33
and old email (also predating DNS) proposing online, real-time public
key serving
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12
307 digit number factored
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 307 digit number factored
Date: Wed, 23 May 2007 16:30:59 -0600
To: James A. Donald <jamesd@echeque.com>
CC: cryptography@metzdowd.com <cryptography@metzdowd.com>,
Ivan Krstić <krstic@solarsail.hcs.harvard.edu>
James A. Donald wrote:
The problem is organizational. To get one decision centrally made and
imposed on everyone requires a central body capable of making
decisions and imposing them on everyone, and before it can get that
authority, that central body usually has to raze Atlanta and burn the
crops, or inflict genocidal famine on the Ukraine.
The great strength and great weakness of the internet is that it is an
anarchy. Anything that requires one decision made for all, such as
the domain name system, got frozen when the internet became too large
for decision making by consensus, and is now extremely difficult to
change.
So to make changes, they have to be made incrementally: You need a CA
with the proposed policy and a deal with several registrars, and that
CA needs to get on the Mozilla and IE list. Nice selling point. If
you register with, say OpenSRS, you would automatically get an SSL
cert. Unfortunately, the certification process for a CA to get on the
browser list seems to be somewhat circular - to be a CA, you have to
prove you are like existing CAs, which is most easily done if you
*are* an existing CA, and have no intention of changing the way you
work.
re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
... that could be the short term view ... as well as dealing with
established operation ... having been around since before the current
CA stuff started ... and somewhat involved in helping get the current
infrastructure established (from the standpoint of its inception for
what is now called electronic commerce ... and having to do detailed
business process & technical walk thru and audit of the early
certification authority players) ... the issue is more how to replace
something once it was established (i.e. the current infrastructure
somewhat got fast uptake ... because it didn't have alternative
solutions to deal with).
re:
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
somewhat topic drift with DNS related trivia ... more than a decade before
DNS
https://www.garlic.com/~lynn/2007k.html#33
and some old email (predating dns) suggesting online, realtime public key
server
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12
307 digit number factored
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 307 digit number factored
Date: Thu, 24 May 2007 14:07:04 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx <cryptography@xxxxxxxx>,
Ivan Krstić <krstic@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
part of the quick IETF uptake of SSL and VPN in the 94/95 time-frame
was that there really wasn't any serious competition. there was ipsec
... but it was end-to-end implementation at low level ip-stack
... which were kernel implementations ... and then was faced with the
whole issue of distribution, installation and support of new kernels
on machines all around the world (from a variety of different vendors
and different operating systems).
SSL was almost a no-brainer ... since it just involved
loading/installing a new application (orders of magnitude easier than
ipsec). lots of collected posts mentioning SSL and/or SSL certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert
in the same time-frame VPN was introduced at the gateway committee
meeting at '94 San Jose IETF meeting. We had worked with the guy on
and off since the late 70s and he originally developed the technology
for his own use ... between home and office; actually both his wife
and he worked for different technology companies ... he got a leased
line from the house to his office ... and her company got a circuit
from his office to their office. The issue was how to encrypt the
wife's communication w/o having it exposed to the husband and/or the
husband's company.
sort of the state-of-the art had been link encryptors ... for a little
topic drift ... the internal corporate network had been larger than
the arpanet/internet from just about the beginning until possibly
summer of '85. the internal network required encryption on everything
leaving the premise ... and in the mid-80s there were comments that
the internal network had over half of all link encryptors in the
world. misc. past posts mentioning the internal network.
https://www.garlic.com/~lynn/subnetwork.html#internalnet
the requirement that led to VPN was how to carry separately encrypted
streams over the same link. ipsec would have solved the problem
... but again was end-to-end solution that required upgrading all the
low-level ip-stacks ... which required distribution, installation (and
support) of new kernel. the VPN solution was to handle the stream
encryption/decryption in boundary routers (which could be tunneled
over other infrastructure).
my observation was this resulted in some amount of consternation in
the ipsec faction ... which they somewhat resolved by starting to
refer to VPN as "lightweight ipsec" (and of course, everybody else
could then refer to regular ipsec as "heavyweight ipsec").
the other problems was with various router vendors in the IETF. it was
sort of divided along the lines of the vendors that had enuf horse
power in their current boxes to implement and deploy VPN support
... and the other vendors whos' products didn't have enuf processing
power available to do the crypto operations in support of VPN. This
difference dragged out some of the VPN standardization activity within
IETF.
misc. past posts mentioning "lightweight ipsec"
https://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection against DOS
https://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec
https://www.garlic.com/~lynn/2007d.html#37 MAC and SSL
https://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip
for other drift ... some of the people doing VPN implementations were
using RSA bsafe library ported to whatever processor they were
using. Some number of these put in effort to enhance the performance
of bsafe library.
some of this was going on when we were in transition from working on
the infrastructure that is currently frequently referred to as
electronic commerce and work in the x9a10 financial standard
committee. in that same time frame there were other efforts looking at
"enhancing" how payment transactions could be implemented and deployed
for the internet (as opposed to x9a10 standards work which had a
requirement to have a standard that preserved the integrity of
financial infrastructure for ALL retail payments).
One of these published some of their specification and from the
specification I drew up a business operation profile and a "public
key" operation profile. I then got the "public key" operation profile
executed on a number of different platforms using the "speeded up"
bsafe library (running four times faster) ... and reported the numbers
back to the organization responsible for that specification. The
people in the organization "claimed" that the performance numbers were
one hundred times too slow (instead of observing that they were four
times too fast). About six months later when they actually had some
prototype code ... the "profile" numbers were within a couple percent
of measured (the speeded up bsafe library having been returned to
rsa).
307 digit number factored
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 307 digit number factored
Date: Thu, 24 May 2007 16:25:31 -0600
To: StealthMonger <StealthMonger@xxxxxxxx>
CC: cryptography@xxxxxxxx
StealthMonger wrote:
This would destroy the protection of one who depends on off-line,
message-based communication for self-defense.
Such a person may create and maintain a persistent pseudonym through
untraceable chains of random latency, anonymizing remailers which
thwart traffic analysis through mixing.
On-line, connection-based communication has low latency and can be
traced by traffic analysis.
re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
the credential/licensing/certificate paradigm was certification of
strangers who have never before communicated before ... and there was
no timely, available mechanism for providing information about the
other party (aka the analogy of letters of credit/introduction from
sailing ship days and before).
parties with previous relationship can have available information
about each other based on prior relationship ... or strangers in first
time communication may have access to timely sources of information
about the other party.
the issue wasn't that the offline stranger paradigm didn't exist
... it just was a rapidly disappearing scenario ... aka digital
certificates were somewhat modeled after the sailing ship "days"
letters of credit/introduction for the early 80s offline email
scenario for first time communication between complete strangers
... dial-up local electronic post-office, exchange email, hang-up
... and then potentially faced with first-time email from total
stranger.
while digital certificate wasn't as high a quality information
paradigm as real-time, online ... in this particular scenario, it was
better than the alternative ... nothing.
the issue isn't eliminating digital certificates for the situations
where they may be appropriate ... it is eliminating digital
certificates for uses where they are obsolete, never intended for,
redundant and/or superfluous. For all the situations where digital
certificates and PKI aren't applicable (or redundant and superfluous)
they tend to represent and extraneous and unnecessary business cost
providing little or no added value.
in the wake of some of the original stuff (w/SSL that is frequently no
referred to as electronic commerce) there was some investigations that
looked at adding digital certificate kinds of processing to existing
real time payment transactions
https://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
.... some of the comments was that adding such digital certificate
processing would bring payment transactions into the modern era. Our
observation was that reverting to an offline PKI, digital certificate
processing paradigm would set back real-time payment transactions
several decades. That if you were doing real-time payment transactions
that online, timely processing had significantly higher quality
information processing ... real-time status of public key onfile in
the account record as well as aggregated information ... recent
payment transaction patterns, current balance and/or credit limit,
etc. It was in the wake of that series of exchanges that you saw OCSP
work start in IETF.
We observed that not only was the stale, static digital certificate
addition to real-time payment transactions redundant and superfluous
... that the typical proposals of the period represented a factor of
100 times in payload size bloat (enormous payload cost addition
providing no added benefit) as well as the redundant and superfluous
digital certificate processing increased real-time payment transaction
processing by nearly a factor of 100 times. Misc. past posts
mentioning enormous redundant and superfluous stale static digital
certificate added overhead
https://www.garlic.com/~lynn/subpubkey.html#bloat
A crazy thought?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A crazy thought?
Date: Sun, 27 May 2007 09:19:37 -0600
To: Allen <netsecurity@xxxxxxxx>
CC: cryptography@xxxxxxxx
Allen wrote:
Hi Gang,
In a class I was in today a statement was made that there is no way that
anyone could present someone else's digital signature as their own
because no one has their private key to sign it with. This was in
the context of a CA certificate which had it inside. I tried to suggest
that there might be scenarios that could accomplish this but was told
"impossible." Not being totally clear on all the methods that bind the
digital signature to an identity I let it be; however, the "impossible"
mantra got me to thinking about it and wondering what vectors might make
this possible.
CAs are certification authorities ... they certify some information
they have checked and issue digital certificates that represent that
checking ... somewhat analogous to physical licenses, credentials,
certificates.
most certification authorities aren't the authoritative agency for the
information that they certify ... for the most part they are simply
certifying that they have checked the information with whatever
authoritative agency is responsible for that information.
in that sense they are somewhat like notary ... i.e. if somebody has
done some identity theft and managed to obtain a valid driver's
license ... the notary isn't held responsible ... they just notarize
that they checked a valid drivers license.
this is somewhat the catch-22 scenario in recent posts for ssl domain
name certification authorities
https://www.garlic.com/~lynn/subpubkey.html#catch22
where they are in something of a situation because big part of the
original justification for ssl domain name certificates involved
integrity issues with the domain name infrastructure ... however, the
domain name infrastructure is also the authoritative agency for domain
name owner information, which the ssl domain name certification
authority is dependent on as part of the integrity for certifying ssl
domain name information. Fixing integrity issues in the domain name
infrastructure ... improves the probability that correct ssl domain
name certification is being performed ... but fixing integrity issues
in the domain name infrastructure can also drastically reduce
justification for having ssl domain name certificates.
recent posts
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored
in some cases, there is the possibility that the excessive attention
to the details of the cryptographic operations is pure obfuscation
that the rest of the end-to-end business processes may purely be built
on a house of cards.
for additional drift, some recent posts in related thread on digital
certificates in another fora (including some possible infrastructure
vulnerabilities and systemic risks)
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#9 Re: John W. Backus, 82, Fortran developer, dies
Identity resurges as a debate topic
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: June 7, 2007 04:41 PM
Subject: Identity resurges as a debate topic
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000931.html
so can I kick off some here
i've somewhat interacted with some of the parties/players in the
identity sphere ... part of it involves
- reducing principles of authentication & authorization to its
fundamental, atomic (KISS) units ... as in attempting to show a way of
moving from an institutional-centric hardware token (something you
have) paradigm to a person-centric hardware token paradigm ... recent
post on subject
https://www.garlic.com/~lynn/2007l.html#8
- working the concepts into the structure of my merged security
taxonomy & glossary (which some of the identity related standards work
have referenced):
https://www.garlic.com/~lynn/index.html#glosnote
in the past couple days, i got an inquiry from one of the "identity"
players about expanding the security taxonomy/glossary with more
identity related concepts. I've gone ahead with a start using a number
of ".gov" sources ... including GSA's federated identity management
manual.
authentication basically comes down to having high confidence that you
are who you claim to be (aka involves identity). authorization
basically comes down to permissions for the specific
entity. frequently authentication and identification get confused
basically it is relatively straight-forward to aggressively
cost-reduce a something you have hardware token ... even if
multi-factor authentication gets involved ... with token support for
something you know and/or something you are authentication
... from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
lots of the complexity isn't from straight-forward authentication
principles .... its getting confused with the authorization
characteristics. lots of the hardware tokens aren't aggressively cost
reduced ... they have lots of hand-waving about added value ... almost
all of this carries with it lots of personal information. one possible
scenario is that all the personal information can't be interpreted as
related to "authentication" ... i.e. relying party grants permissions
and privileges based on personal/privacy characteristics (aka it is
getting heavily involved in authorization as "added" value).
this is left over from the offline world ... my frequent reference to
explaining that the PKI digital certificate (which many of the
hardware tokens are starting to emulate) is an electronic analog to
physical credentials, certificates, licenses ... along the lines of
the letters of credit/introduction from the sailing ship days (and
earlier) when the relying party would be having first time interaction
with a total stranger and unable to directly confer/check with any
possible reference. the apparent tendency in the early to mid 90s was
to grossly overload an x.509 identity digital certificate with
enormous amounts of personal information ... as a means of aiding
relying parties in authorization decisions (unrelated to any
authentication and identity). it was in the mid-90s that there started
to be some realization that such digital certificates, grossly
overloaded with personal information represented significant privacy
and liability issues. this led to the "replying-party-only" digital
certificates ... which contained only sufficient information for
authentication (identity)
https://www.garlic.com/~lynn/subpubkey.html#rpo
all the necessary personal information necessary for authorization
then was obtained from some other source (once authentication had been
performed). however it was trivial to show that relying-party-only
certificates were redundant and superfluous ... since ALL the
information the information for both authentication and authorization
could be obtained from the same source ... and therefor it was
possible to have a digital signature verification infrastructure (for
both authentication and authorization) that had no need for PKI and
digital certificates
https://www.garlic.com/~lynn/subpubkey.html#certless
so i would claim that the "identity" for the authentication part can
be extremely simple and cost-effective (KISS). frequently it is the
inclination to include enormous amounts of personal information as an
aid allowing "relying parties" to base "authorization" decisions. It
is also such enormous amounts of personal information that result in
the privacy and liability issues.
this has led to the added value variations (digital certificates and
hardware tokens) moving into the "no value" market segment
... i.e. environments where the relying party operations can't justify
cost of their own information repository about individuals and/or
justify online connectivity to some authoritative agency. the downside
of moving into "no value" market segments is that it becomes even more
difficult to justify the cost of any added value offerings.
so my tendency would be to claim that some amount of the whole swirl
around "identity" ... isn't related to identity for authentication; it
is all the possible enormous amounts of personal information that
opens up the responsible agency for both privacy invasive liability
from the individuals (possibly from data breaches) as well as any
related authorization liability from relying parties (how to provide
sufficient personal information so that relying parties can make
authorization decisions w/o incurring any legal liability).
the other historical scenario (related to cross-domain, federated,
etc) swirl around identity is all the stuff that there was in the 90s
with PKIs trying to define cross-infrastructure operation for digital
certificate (enormous amounts of privacy information as aid in
cross-domain authorization decisions).
we had run into the same scenario nearly a decade earlier in a prior
life when we were working for one of the companies that provided half
of the funding/grants for MIT's Project Athena. Kerberos
(authentication) was originally work done at Project Athena ... and it
was one of the projects we would get to periodically review. We
happened to be there when there was a week of working sessions on the
initial details of Kerberos cross-domain support. More recently we sat
thru a presentation on a SAML implementation where the message flows
were essentially identical to what was worked out for cross-domain
Kerberos (except using SAML encoded messages).
Later there was the pk-init draft for Kerberos ... registering public
keys in lieu of passwords for authentication ... again a purely
certificate-less public key mode of operation. Somewhat after that,
there was heavy lobbying to also add definition for certificate-mode
of operation to the pk-init draft. Since then, one of the principles
behind that (digital certificate) lobbying effort has periodically
contacted us to apologise (i.e. digital certificate mode of operation
for Kerberos being redundant and superfluous). misc of past posts
mentioning Kerberos
https://www.garlic.com/~lynn/subpubkey.html#kerberos
Why self describing data formats:
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Why self describing data formats:
Date: Sat, 09 Jun 2007 13:17:17 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
James A. Donald wrote:
Many protocols use some form of self describing data format, for example
ASN.1, XML, S expressions, and bencoding.
Why?
gml (precursor to sgml, html, xml, etc)
https://www.garlic.com/~lynn/submain.html#sgml
was invented at the science center in 1969
https://www.garlic.com/~lynn/subtopic.html#545tech
... some recent (science center) topic drift/references in this post
https://www.garlic.com/~lynn/2007l.html#65 mainframe = superserver
"G", "M", & "L" were individuals at the science center ... so the
requirement was to come up with an acronym from the inventors initials
so some of the historical justification for the original "markup language" paradigm
can be found
originally CMS had the script command for document formating ... using
"dot" format commands ... i.e. science center on 4th flr of 545 tech sq
doing virtual machines, cp67, cms, the internal network, etc ... and multics
on 5th flr of 545 tech sq ... draw from some common heritage to CTSS (and some
of the unix heritage traces back thru multics also to CTSS).
the original GML was sort of a combination of "self-describing" data (somewhat for
legal documents)
https://web.archive.org/web/20231001185033/http://www.sgmlsource.com/history/roots.htm
http://xml.coverpages.org//sgmlhist0.html
and document formating ... when GML tag formating was added to CMS script processing
command. Later you find a big CMS installation at CERN ... and HTML drawing heritage
from the "waterloo" clone of the CMS script command.
http://infomesh.net/html/history/early/
first webserver outside of europe was at slac (a CERN "sister" location) ... another
big vm/cms installation:
https://ahro.slac.stanford.edu/wwwslac-exhibit
recent historical post/reference
https://www.garlic.com/~lynn/2007d.html#29 old tapes
last time i checked, w3c hdqtrs was around the corner from the old
science center location at 545 tech. sq.
before GML, the science center had an activity involving "performance" data
from the time-sharing service (originally using virtual machine cp67 service
and then transitioning to vm370) ... lots of system activity data was captured
every 5-10 minutes and then archived to tape ... starting in the mid-60s ...
by the mid-70s there was a decade of data spanning lots of different configurations,
workloads, etc. The original intention when the system activity data was being
archived was to include enuf self-describing information that the data could
be interpreted many yrs later. lots of past posts about using cp67&vm370
for time-sharing services (both for internal corporate use and customers offering
commercial, online time-sharing services using the platform)
https://www.garlic.com/~lynn/submain.html#timeshare
lots of past posts about long term performance monitoring, workload profiling,
benchmarking and stuff leading up to things like capacity planning
https://www.garlic.com/~lynn/submain.html#benchmark
much later, you find things like ASN.1 encoding for handling interoperability
of network transmitted data between platforms that might have different
information representation conventions (like the whole little/big endian stuff).
one of the things swirling around digital signature activity in the mid-90s
was almost religious belief that digital certificate encoding mandated
ASN.1.
other digital signature operations that were less religious about PKI,
x.509 identity digital certificates, etc ... were much less strict
about encoding technique for digitally signed operations ... included
certificate-less digital signature infrastructures
https://www.garlic.com/~lynn/subpubkey.html#certless
One of the battles during the period between XML and ASN.1 proponents
during the period was that XML didn't provide for a deterministic
encoding. It really was somewhat a red herring on the digital
certificate ... ASN.1 side ... since they were looking at always
keeping things ASN.1 encoded (not just for transmission) ... and only
decoding when some specific information needed extraction.
On the other side was places like FSTC which was defining digitally
signed electronic check convention (with tranmission over ACH or
ISO8583). There was already a transmission standard ... which ASN.1
encoding would severely bloat ... not to mention the horrible payload
bloat that was the result of any certificate-based infrastructure
needing to append redundand and superfluous digital certificates.
https://www.garlic.com/~lynn/subpubkey.html#bloat
FSTC just defined appending a digital signature to existing payload.
The issue then became a deterministic encoding of the information for
when the digital signature was generated and verified. If you
temporarily encoded the payload as XML, generated the digital
signature ... and then appended the digital signature to the standard
(ACH or ISO8583) payload ... the problem was that at the other end,
XML didn't provide a deterministic encoding methodology so that the
recipient could re-encode the payload and verify the digital
signature. So FSTC eventually defined some additional rules for XML
called FSML ... which then was turned over to W3C as part of XML
digital signature activity.
There was something of a cultural class between the FSTC orientation
and much of the x.509 standards environment. In the FSTC world ... the
information is only temporarily encoded for digital signature
generation and verification; the rest of the time, the data is in some
native usable form. In the X.509 standards environment, the data
tends to always remain encoded in ASN.1 format ... and is only
(temporarily) decoded when it is actually needed to be used/accessed.
Why self describing data formats:
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: James A. Donald <jamesd@xxxxxxxx>
Subject: Re: Why self describing data formats:
Date: Sat, 09 Jun 2007 13:39:33 -0600
CC: Cryptography <cryptography@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:
for other archaeological trivia ... later i transferred from the
science center to SJR and got to do some of the work on the original
relational/sql implementation, System/R.
a few years later, the "L" in GML also transferred to SJR and worked
on relational, included being involved in the development of of BLOBS
(Binary Large OBjectS) for relational.
roll forward a few yrs to the acm (database) sigmod conference in san
jose in the early 90s. In one of the sessions, somebody raised the
question about what was all this X.500 and X.509 stuff going on in ISO
... and there was somebody from the audience that explained how it was
a bunch of networking engineers trying to re-invent 1960s database
technology.
today ... you can periodically find heated online discussion about XML
"databases" and whether they compromise the purity of information
integrity that you get from the relational paradigm. lots of past
posts mentioning various things about system/r, relational database
technology, etc
https://www.garlic.com/~lynn/submain.html#systemr
A crazy thought?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A crazy thought?
Date: Sat, 09 Jun 2007 14:27:21 -0600
To: Allen <netsecurity@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
for some other topic drift regarding certification authorities
... having been certification authorities for "digital certificates"
targeted at the (electronic but) "offline" market ... they encountered
a number of issues in the mid-90s as the world was transitioning to
ubiquitous online operation ... the digital certificates were somewhat
targeted for relying parties ... dealing with total strangers (that
they had no prior information about) and had no timely mechanisms for
directly contacting any authorities for references regarding the
stranger.
so one of the issues for x.509 identity certificates ... small x-over
from this other thread
https://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats
was to try and move out of the no-value market into the identity
market ... aka ... as world transitioned to ubiquitous online
operation ... the remaining "offline" was "no-value" situations where
the relying-party couldn't justify the cost of maintaining information
about the parties that they dealt with (aka something analogous to
browser "cookies") and/or couldn't justify the cost of directly
contacting responsible agencies for information about the parties they
were deailing with.
now in this recent thread ... somewhat about some internet historical
evolution
https://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#68 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#69 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#70 nouns and adjectives
the last post drifts into the subject of some of the recent "churn"
around identity activities ... also lengthy post on the subject
here:
https://www.garlic.com/~lynn/aadsm27.htm#23 identity resurges as a debate topic
the certification authorities were somewhat looking at increasing the
value of x.509 identity digital certificates (since there wasn't a lot
of future selling into the no-value market segment) by starting to
grossly overload the digital certificates with enormous amounts of
personal information.
now typically identity has been a authentication characteristic
... adding potentially enormous amounts of personal information could
be considered attempting to move into the authorization area
... where a relying-party might be able to make a authorization,
approval, and/or permission decision purely based on the additional
personal information in the digital certificate.
what was seen by the mid-90s was that many of the institutions were
starting to realize that x.509 identity digital certificates, grossly
overloaded with personal information represented significant privacy
and liability issues. what you saw then was a retrenchment to purely
authentication, relying-party-only digital certificate
https://www.garlic.com/~lynn/subpubkey.html#rpo
with the digital certificate containing little more than a record
locator (where all the necessary information was actually kept, even
real-time, and aggregated information ... which is difficult to
achieve in a stale, static digital certificate paradigm) and a public
key ... note, however, we could trivially show that in such situations
the stale, static digital certificate was redundant and superfluous
... aka just add the public key to the entity's record ... which
already had all the personal, private and other information necessary
for authorization. in the payments market segment ... this is
somewhat separate from the fact that the appended stale, static,
redundant, and superfluous digital certificates were causing a factor
of 100 times payload and processing bloat
https://www.garlic.com/~lynn/subpubkey.html#bloat
one of the other problems faced by certification authorities
attempting to move identity digital certificates into the
authorization market segment was what (with loads of personal
information), if any, liability were certification authorities going
to accept with regard to authorization problems encountered by the
relying-parties (depending on the digital certificate personal
information in their decision making process).
A crazy thought?
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A crazy thought?
Date: Sat, 09 Jun 2007 18:02:10 -0600
To: Jim Dixon <jdd@xxxxxxxx>
CC: Allen <netsecurity@xxxxxxxx>, cryptography@xxxxxxxx
Jim Dixon wrote:
The CA certifies that X is your public key. It doesn't know what your
private key is.
If the CA starts handing out false public keys - which is the worst
that it could do, right? - it will find itself instantly distrusted.
Everybody in the world will be able to see that the CA used its private
key to sign a false statement. The offended party need only put the
false declaration up on the Web.
CAs actually tend to certify that they were able to verify a supplied
digital signature with a supplied public key ... with the implication
that the entity who supplied the signature & key ... had access to the
corresponding private key, in order to generate the signature
(aka something you have authentication model).
CAs then may also certify that they were able to verify some amount
of other information related to the entity supplying the signature
and public key.
the existence of a certified digital certificate with a different
public key ... can be on the order of various kinds of identity
theft ... and as equally difficult to deal with.
for instance ... it may not be sufficient that you can prove that there
are two distinct, different digital certificates ... in the identity
theft scenario ... it may also going to require that the disputed
digital certificate couldn't possibly apply to you (which is more than
just that it is not the same as the digital certificate you are
owning up to).
previous posts in thread:
https://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
https://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?
A crazy thought?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A crazy thought?
Date: Sat, 09 Jun 2007 18:34:42 -0600
To: Ian G <iang@xxxxxxxx>
CC: Allen <netsecurity@xxxxxxxx>, cryptography@xxxxxxxx
Ian G wrote:
What you are suggesting is called Web of Trust (WoT). That's what the
PGP world does, more or less, and I gather that the SPKI concept
includes it, too.
However, x.509 does not support it. There is no easy way to add
multiple signatures to an x.509 certificate without running into support
problems (that is, of course you can hack it in, but browsers won't
understand it, and developers won't support you).
re:
https://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
https://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?
https://www.garlic.com/~lynn/aadsm27.htm#27 A crazy thought?
actually ... at a very fundamental level both PKI and PGP have nearly
identical business and implementation processes ... the difference is
somewhat that the PKI operations tend to try and make out that their
structure is more formal ... and therefor should be more trusted.
Both implementations require that the relying-parties have some sort
of local trusted public key repository ... initially populated with
some out-of-bad process. In the SSL PKI scenario ... there tends to be
a trusted public key repository built into each browser distributed
... initially loaded with possibly 40-50 public keys that you are told
that you can trust. In the "web of trust" scenario ... there tend to
be some set of public keys that are also trusted and have also been
acquired in some out-of-band process.
In both scenarios ... the relying-party is expected to "trust" new
public keys that carry digital signatures ... where these digital
signatures can be verified with public keys from their local
repository of (already) trusted public keys (public keys that have
typically been distributed/initialized by some out-of-band process)
It isn't so much that the fundamental processes are different ... it
is more about how tightly controlled and cast in concrete the
surrounding pieces happen to be (aka formalized and not easily
changed/adapted).
For totally other drift ... one of the places we came up with
requirement for multiple digital signatures was in the process for
x9.59 financial infrastructure for payment transactions ... i.e. in
the mid-90s, the x9a10 financial standard working group had been given
the requirement to preserve the integrity of the financial
infrastructure for all retail payments
https://www.garlic.com/~lynn/x959.html#x959
x9.59 actually doesn't specify the details of digital signature
process ... but defines the fields necessary for a payment
transactions which require authentication and integrity protection on
end-to-end basis. one of the scenarios is the authentication of the
account holder with digital signature (which also provides payment
transaction integrity). one of the trust issues was that there could
be various kinds of exploits at the originating environment (where the
account holder's digital signature and the transaction was otherwise
valid). to increase the trust (as indication of possible
countermeasures against these additional exploits/vulnerabilities)
allowed for the originating environment to also digitally sign the
transaction (as a flavor of "device" authentication, possibly a
point-of-sale terminal or other kind of device that was used to
originate the transaction).
the FSTC electronic check work also allowed for multiple digital
signatures ... representing the equivalent of requiring multiple
co-signers on business checks ... i.e. business checks that allow for
single signer if the amount is below some limit ... but requires
additional co-signers for larger amounts.
note that both in the FSTC electronic check and the X9.59 financial
standard scenario, there was some assumption that the basic
transaction went via normal existing electronic payment networks
... with appended digital signature(s) ... where the transaction might
actually only be encoded during just the digital signature generation
and digital signature verification processes. recent posts in the
encoding thread:
https://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:
https://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats:
also any additional appending of traditional digital certificates to
such operations could represent a factor of 100 times payload and
processing bloat.
https://www.garlic.com/~lynn/subpubkey.html#bloat
A secure Internet requires a secure network protocol
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: A secure Internet requires a secure network protocol
Date: Fri, 22 Jun 2007 10:30:27 -0600
To: Cryptography <cryptography@xxxxxxxx>
A secure Internet requires a secure network protocol
http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html
from above:
Implementing -- and requiring -- stronger authentication and
cryptography standards is the next step toward a new Internet
... snip ...
i would contend that majority of exploits are attacks on (vulnerable)
end-points ... not directly involving any actual network protocol or
cryptography; this includes (updated) variations on old-time "social
engineering" ... which has some relation to authentication (between
end-points) ... but on par with crooks using the telephone to call
people and convince them of one thing or another (and then suggesting
that encrypting the telephone call transmission would eliminate the
problem).
one of the things seen in various of the SSL (authentication)
vulnerabilities ... are attackers being able to ("authenticate") prove
who they claim to be ... however, who they claim to be for SSL
authentication ... and who they claim to be for their "social
engineering" attacks ... may not be exactly the same.
As before, one of the largest class of attacks (not restricted to
internet) are against information related to payment transactions and
which (largely because of weak authentication in unrelated parts of
the infrastructure) is then turned around and relatively easily used
for fraudulent financial transactions. misc. past posts on the theme
of "naked" transactions.
https://www.garlic.com/~lynn/subintegrity.html#payment
A secure Internet requires a secure network protocol
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A secure Internet requires a secure network protocol
Date: Sat, 23 Jun 2007 07:37:02 -0600
To: Alex Alten <alex@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Alex Alten wrote
SSL seems to be hanging by a thread, mainly the name to public key
mapping depends on how thorough the checking is done in to SSL vs
application layers inside of the web browser. If this is hosed then
unrestricted MITM is in the cards sometime in the near future.
re:
https://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure network protocol
i.e. we were called in to consult with this small client/server
startup that wanted to do payments on their server. they had this
technology they called SSL ... and we had to end-to-end process audits
... including walk-thru of some of these new business entities that
were calling themselves certification authorities.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
the fundamental SSL design point was that the user knows the
relationship between a website and a URL, the user entered that URL,
and SSL would authenticate that the website that the user *thot* they
were talking to (from entering the URL), was in fact, the website they
were actually talking to.
these days, most users have no cognition about relationship between
websites and URLs, they click on something in email and/or
webpages. In this scenario, the attacker is providing the URL and then
the only thing that SSL is providing is authenticating who the
attacker is claiming to be (via the URL that the attacker provides).
the original SSL design point had implicit assumptions that users knew
the relationship between the website they thot they were talking to
and URLs (and then SSL authenticated the relationship between those
known URLs and the website). For the most part those assumptions are
no longer valid ... which then breaks the security model and all bets
are off. With the potential attacker frequently providing both the URL
and the website, then the only thing SSL is providing is
authenticating the website that the attacker claims to be (via the
URL) is the website that they are (breaking original basic assumption
about SSL). This totally invalidates the assumption that SSL is
proving that the website that the user *thot* they were talking to
(via directly entering the URL) was, in fact, the website that they
were talking to (aka the user has no idea what website they are
talking to ... because they no longer have the knowledge about the
relationship between websites they think they are talking to and the
URLs for those websites).
The (URL) name to key mapping isn't the problem ... that is the
mechanics that SSL provided. The problem was that SSL security had
implicit assumption that the user knew the mapping between the website
they think they talk to and the URL for that website. In the current
environment, that assumption is no longer valid,
So the basic, most common PKI infrastructures provide a trusted public
key repository (typically manufactured into browsers before they
ship). Users are indoctrinated that they can trust those public keys
... for the purposes of digitally signed CA digital certificates. These
digital certificates provide the binding between URL (actually the
domain names part of URL) and website public keys. It is imperative
that the user (knowledge) then provide the binding the website they
think they are talking to and the URL. That is the part that is
missing in today's environment (and what large numbers of attackers
can leverage to slip thru the "cracks").
The missing piece is trusted binding between who the user's think they
are talking to and the URL (or at least domain name). This could be
accomplished by a separate trusted repository ... names that the
end-user relates to and trusted binding between those names and
URLs. Attacker provided URLs that are clicked on ... then can be
cross-checked with things in that new trusted table (analogous to the
way that the browser table of certification authority public keys are
trusted).
Then the issue is that if there is a trusted table mapping names to
URLs (or at least domain names) ... and a separate table of trusted
public keys ... the whole thing could be collapsed into a single table
... totally eliminating the level of indirection provided by
(redundant and superfluous) PKI and certification authorities ... just
add the public key to the trusted table of names & domain names (aka
URLs).
The issue isn't so much that SSL is broken ... it is the implicit
dependency on users knowing the relationship between the website they
think they were talking to and the URL for those websites. Creating a
user trusted table of website/urls (analogous to the browser trusted
table of certification authority public keys), can make PKIs and
certification authorities redundant and superfluous ... since in
whatever trusted process is used to maintain the trusted table of
website/urls ... can also directly include the public key for those
website/urls.
this is similar, but different to some of the domain name
infrastructure proposals that would allow real-time retrieval of
on-file, domain name public keys (also making PKIs and certification
authorities redundant and superfluous). Some past posts discussing
catch-22 for PKI infrastructures with real-time domain name
infrastructure public keys
https://www.garlic.com/~lynn/subpubkey.html#catch22
other posts about certificate-less public key operation
https://www.garlic.com/~lynn/subpubkey.html#certless
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 08:23:00 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx <cryptography@xxxxxxxx>,
dan@xxxxxxxx, Leichter, Jerry <leichter_jerrold@xxxxxxxx>
Peter Gutmann wrote:
(The usage model is that you do the UI portion on the PC, but
perform the actual transaction on the external device, which has a
two-line LCD display for source and destination of transaction,
amount, and purpose of the transaction. All communications enter
and leave the device encrypted, with the PC acting only as a proxy.
Bill of materials shouldn't be more than about $20).
The decade or so old EU FINREAD standard is along this line ... sort
of modeled after point-of-sale terminal ... includes its own display
and pinpad (countermeasure to keyloggers). lots of past posts
mentioning EU FINREAD standard
https://www.garlic.com/~lynn/subintegrity.html#finread
the actual communications that enter and leave aren't required to be
encrypted ... the communication that enter are revalidated on the
display ... and the communication that exits is on the order of an
x9.59 transaction
https://www.garlic.com/~lynn/x959.html#x959
that are armored with digital signature (integrity and authentication)
... misc. posts mentioning "naked" transaction metaphor
https://www.garlic.com/~lynn/subintegrity.html#payments
old aads chip strawman from nearly decade ago postulated form factor
agnostic ... that could even be added to existing pda/cellphone for a
lot less and communicate wirelessly.
https://www.garlic.com/~lynn/x959.html#aads
in the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments. part of the detailed
end-to-end risk and threat analysis was not only the end-point
vulnerabilities but also the large number of business processes that
are giving rise to security breaches and data breaches
that have frequently made the press. part of x9.59 transaction
armoring was that all the transaction information could be readily
exposed and still not be useful to attackers for performing fraudulent
transactions. This was countermeasure to all the breaches
... regardless of whether insiders or outsiders were involved ... it
was recognized that the transaction information had to be exposed in a
large number of business processes. Recognizing the impossibility of
eliminating all such information exposure ... the x9.59 approach was
to eliminate the risk and fraud associated with such exposures
(i.e. impossible to eliminate all the breaches ... so eliminate the
risk and fraud associated with such breaches).
We had previously been called in to consult with small client/server
startup that wanted to do payment transactions on their server
https://www.garlic.com/~lynn/subnetwork.html#gateway
and had this technology called SSL that they wanted to use. The issue
in SSL was that it hid the information while moving thru the internet
... but left it totally exposed at all other points (and in fact the
numerous business processes required such exposure). the x9.59
approach was then not to try and eliminate all such exposures ... but to
eliminate the risks associated with all exposure of the information
(in effect, armoring the transaction w/o requiring the information to
be hidden as countermeasure to fraudulent transactions).
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 10:06:45 -0600
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>, dan@xxxxxxxx,
"Leichter, Jerry" <leichter_jerrold@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
slight addendas ...
1) EU finread
https://www.garlic.com/~lynn/subintegrity.html#finread
https://www.garlic.com/~lynn/subintegrity.html#assurance
one of the issues that we looked at early on in x9.59 standard
... somewhat related to the EU finread ... was what proof did the
financial institution have as to the integrity of the originating
end-point (for doing risk assessment purposes). With this motivation,
X9.59 standard allowed for multiple digital signatures ... which could
include device authentication for finread-like devices (giving some
assurance as to the integrity of the originating end-point)
2) liability
there appears to be a lot more motivation for improving assurance in
the online banking scenario ... say, as opposed to e-commerce and
retail payments. in the e-commerce and retail payments ... financial
institutions can charge off a lot of fraud to the merchants (buried in
things like interchange fees). in the online banking scenario,
merchants aren't part of the scene ... just leaving the consumer and
the financial institutions as the responsible parties.
....
misc. recent financial news items ...
Police arrest three suspects in credit card investigation
http://www.redlandsdailyfacts.com/news/ci_6262066
ACH Fraud: Clearing House Aims To Clean House
http://www.banktechnews.com/article.html?id=200706260ZQVU91V
Mobile wallets to replace payment cards - report
http://www.finextra.com/fullstory.asp?id=17116
Debit Scam used 'parasite' pin pads
http://www.canada.com/vancouversun/story.html?id=773122d5-556f-4b50-87bc-2dc2ad205126&k=24040
Shoppers 'easy prey' for debit card fraud
http://www.canada.com/vancouversun/news/story.html?id=8e460eed-1bab-4848-9f4c-eefbaecc5ab8
...
in the early aads chip strawman (from the 90s)
https://www.garlic.com/~lynn/x959.html#aads
form-factor agnostic in user "owned" pda/cellphone were countermeasure
to foreign, unfamiliar POS-terminals that possibly were compromised
(i.e. paranoid consumers could have some responsible control over
their own devices ... as opposed to POS-terminals at random merchants)
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 13:38:14 -0600
To: Ian G <iang@xxxxxxxx>
CC: Florian Weimer <fw@xxxxxxxx>,
"Leichter, Jerry" <leichter_jerrold@xxxxxxxx>,
dan@xxxxxxxx, cryptography@xxxxxxxx
Ian G wrote:
Unfortunately for the banks, there is a vast body of evidence that
we knew and they knew or should have known that the PC was insecure
[1]. So, by fielding a system -- online commerce -- with a known
weakness, they took responsibility for the fraud (from all places).
re:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
i.e. to large extent, the existence of the EU finread standard is
proof of attempt at countermeasures to the (known) PC integrity
weaknesses.
the original electronic-commerce adopted the MOTO model
(mail-order/telephone-order) which placed significant responsibility
on the merchant ... AND there was some presumption that physical goods
were involved, shipping to a known address. SSL was used as
compensating process, in theory, placing internet-order on level
playing field with MOTO.
as electronic-commerce deviated more & more from the MOTO-model
and related assumptions ... there were increasing risks and
vulnerabilities.
one of the early problems ... in the electronic-commerce genre ...
was what to do with purely internet merchants. in the standard MOTO
model ... there is consumer financial institution, financially
responsible for the consumer and merchant financial institution,
financially responsible for merchants (with merchant interchange fees
largely underwriting the whole environment).
merchant financial institutions tended to sponsor merchants where
there were physical assets available for seizure ... equivalent to a
month or two of credit card transactions. With every transaction
passing thru the sponsoring organization (or its agent), the merchant
financial institution had real-time knowledge of the outstanding
exposure and risk (and was capable of cutting things off at a moments
notice). However, a lot of internet merchants were setting up as
purely order fulfillment organizations with little in the way of
physical assets. In the early electronic commerce days there were
some intense lobbying that went on with the risk management
departments in merchant financial institutions.
But as mentioned in previous post ... the move to online banking ...
removes the merchant completely from the picture (it is no longer the
electronic commerce MOTO-model) ... leaving just the end-user and
their financial institution as the responsible parties.
In the mid-90s, financial institutions looking at the internet for
online, commercial banking and cash management (i.e. business
equivalent to consumer online banking) were extremely conflicted
... they frequently were almost insisting on their own appliance at
the business (and low-end of SOHO at least overlaps high-end of
consumer online banking).
Various of the PC-based dedicated financial applications go to quite
some lengths to compensate for kind of vulnerabilities typically
associated with browser activity. For instance, instead of relying on
a trusted third party to certify that some remote location really has
a valid digital certificate, they have a trusted repository of valid
financial institutions. This is somewhat the equivalent of the table
of certification authority trusted third parties built into browsers
... but instead of table of certifying parties that can certify other
parties ... it is table of the actual financial institutions. This
has the added benefit of eliminating the horribly complex and
vulnerable PKI-type of operation (an don't rely on certification of
something totally unrelated to financial transaction operation, but
instead rely directly on known financial transaction operation).
https://www.garlic.com/~lynn/subpubkey.html#certless
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 14:49:40 -0600
To: Adam Shostack <adam@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>,
perry@xxxxxxxx, cryptography@xxxxxxxx,
dan@xxxxxxxx, leichter_jerrold@xxxxxxxx
Adam Shostack wrote:
I'd suggest starting from the deployment, training, and help desk
costs. The technology is free, getting users to use it is not. I
helped several banks look at this stuff in the late 90s, when cost of
a smartcard reader was order ~25, and deployment costs were estimated
at $100, and help desk at $50/user/year.
re:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
there was a detailed analysis of the 99/00 smartcard deployments
... looking at the most common causes for problems. this was
overlapped with opinion claimed to be widely held among consumer
financial institutions, that it had been proven that smartcards were
not practical in the consumer market segment.
then, for something of a lark, at the annual smartcard conference, i
went around to most of the booths asking people at the booth if they
were 1) aware that the financial industry considered smartcard not
practical in the consumer market segment and 2) what was the cause of
the majority of the problems.
some of the major deployments selected to be pc/sc compliant ... which
at the time only supported serial port attachment ... and did not
support USB plug&play. It turned out that the vast majority of
smartcard deployment problems in that time-frame had to do with
consumers trying to install serial port card readers, consumers that
couldn't find the serial port, serial port connections that conflicted
with something else, serial port IRQ conflicts, serial port driver
conflicts (large number of BSOD and consumers having to re-install
their systems from scratch).
there was then a very complex and intricate series of negotiations
getting agreement to upgrade pc/sc to support USB plug&play (for
starters, responses like why even bother since it had been proven
already that smartcards weren't practical in the consumer marketplace
... ignoring for a moment that major factor in the failures was the
pc/sc serial port limitations) .
There were also things like alternative packaging ... USB keyboard
with built-in smartcard reader, display, and PIN-pad cut-out switch
... where keyboard incremental cost was more like $5 (but again, it
required PC/SC to be upgraded to USB plug&play)
however, by that time, nearly every where you went, there were echos
that it (some deployment or another) had proven that smartcards were
not practical in consumer environment. Note that it wasn't just
consumer limited, there were instances where commercial operations
figured that it would be on the order of $500/PC to be able to handle
PC/SC serial port smartcard reader attachments.
it was in the midst of these particular disasters that you also saw
some of the smartcard operating system projects being canceled (again
the spreading belief that smartcards were not practical in the
consumer market place). All of this can be pretty much put at the
doors of the institutions failing to understand some of the
fundamental issues attempting to deploy serial-port PC/SC in the PC
market place of the time (and/or understand that large driver behind
doing the whole USB plug&play thing was the significant problem
and issues attempting to deal with the serial port implementation)
some number of past posts mentioning the whole PC/SC serial port
problems encountered with various attempts at smartcard deployments in
the PC/consumer marketplace
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
https://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2003n.html#35 ftp authentication via smartcard
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 17:33:59 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: Ian G <iang@xxxxxxxx>,
"Leichter, Jerry" <leichter_jerrold@xxxxxxxx>,
dan@xxxxxxxx, cryptography@xxxxxxxx
Florian Weimer wrote:
Oh really?
In Germany, early digital banking had no cryptographic protection at
all. Integrity and confidentiality were inherited from the underlying
phone system. There were no end-to-end digital signatures. Nothing.
Just a one-time password for each transaction, but the password was
not tied to the transaction in any way.
> This has the added benefit of eliminating the horribly complex
> and vulnerable PKI-type of operation
Except that there aren't any attacks on the browser PKI. That's part
of the reason why the certificate prices plummeted. 8-/
re:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
there had been lots of home banking with PCs starting in the
80s. these were dial-up into private bank modem pools (both consumer
and business cash management). one of the trade-offs looking at going
to internet based operation is the enormous infrastructure savings to
financial institutions.
in 1995, a presentation by one financial institutions figured that
they had provided and were supporting something like 65 different
modem software drivers (different modems, different operating system
versions, different operating systems, different platforms,
etc). transitioning to internet met that they could eliminate all of
that (lots of help desk, lots of serial port issues, lots of hardware
issues ... a much smaller precursor to the later smartcard PC/SC
serial port disaster).
they talked about what trade-offs were with any conversion to
internet, the operating system vendors and ISPs would go to a common
connectivity operation, bearing the cost of all the online
connectivity ... amortized over a lot of online use (not just online
banking). This eliminated an enormous cost for online banking. The
downside was that the security issues significantly increased.
the dedicated financial applications have some similarities to that
earlier dial-up phone environment ... except they are using something
akin to a controlled SSL encrypted path (tunneled thru the internet)
where the client PC application has preloaded information about the
financial institution's server (not needing traditional PKI trusted
3rd party certification authority to provide information about unknown
parties).
now with respect to weakness of using PKI for such purposes, i've
contended in the past that the image/picture authentication (was
believed to) helped increase the possibility that the consumer/client
was dealing with valid financial institution (that they had previously
registered the image/picture with).
in that sense, it can be viewed as countermeasure to common
phishing attacks ... where clients are convinced to click on some
field that takes their browser to (possibly fraudulent)
webserver. Given that the attacker can supply both the actual URL and
the corresponding SSL digital certificate ... and majority of clients
have very weak binding between websites and the corresponding URL
(i.e. SSL PKI digital certificate is just checking that the webserver
contacted actually corresponds to the supplied URL) .... then
attackers have found an enormous PKI weak link in the current way SSL
is deployed (it relies on the user to provide the binding between the
webserver they think they are talking to and that webserver's URL
... where SSL PKI is then only providing the binding between a URL and
a webserver).
As a result, active MITM attacks have happened ... where
consumer is convinced to click on a field purported to connect them to
their financial institution. The attacker actually provides a URL to
the attacker's webserver, for which the attacker has a valid SSL
digital certificate (i.e. the attacker is abel to prove that they are
who they claim to be, w/o having to prove that they are who the victim
thinks they are) ... then the attacker can transparently pass
communication between the real financial institution website and the
consumer (with two different SSL sessions connected at the attackers
website) ... aka the (registered/selected) image/picture
authentication stuff is to increase the sense of comfort a customer
would have that they are actually talking to their financial
institution (in view of all the SSL short-comings ... however, it
doesn't actually do anything to preclude man-in-the-middle
attack)
lots of past posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
some specific past posts about MITM-attacks and bank site authentication
https://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL ... addenda 2
https://www.garlic.com/~lynn/aadsm26.htm#56 Threatwatch: MITB spotted: MITM over SSL from within the browser
https://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007
part of this harks back to when we were originally called into consult
with this small client/server startup that wanted to do payments on
their servers ... they had this technology called SSL they wanted to
use and it has since come to be frequently called electronic commerce
https://www.garlic.com/~lynn/subnetwork.html#gateway
the end-to-end security "assumptions" at the time was that the user
would type into the browser, the URL of the website they wanted to
connect to. This created the trusted binding between the website the
user wanted to talk to and the URL. Then the browser, using SSL,
digital certificates, PKI, etc ... would validate the correspondence
between the URL and the webserver that was actually contacted (two
part trust operation, both required).
however, fairly early in the deployment, merchants found that using
SSL for the whole shopping experience cut their thruput by 90-90
percent. as a result, they cut SSL use back to just the part for
payment. Now the user can enter a URL ... and it isn't validate with
SSL ... so the user can be talking to an attackers website. Then when
they go to pay/checkout ... they click on a button, provided by
(potential fraudulent) website. The button provides the URL for the
checkout portion ... allowing an attacker to provide both the URL and
an digital certificate that corresponds to that URL.
No longer is SSL being used to provide the correspondence between the
webserver that the user thinks they are talking to and the webserver
they are actually talking to ... the user is getting both the URL and
the digital certificate off the net ... so all an attacker has to show
that the URL they claim to be is the URL that they have a valid
digital certificate for.
lots of past posts about SSL (and effectively SSL digital certificates
turning into a "comfort" item as opposed to a real security feature)
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
For other topic drift, in the mid-90s at one of the large security
conferences (in the US), one of the large German banks gave a talk on
relying-party-only digital certificates ... lots of past posts
mentioning RPO certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
They had realized that the X.509 identity digital certificates (from
the early 90s), potentially overloaded with enormous amounts of
personal information, ... represented significant privacy and
liability issues. As a result, they had retrenched to RPO-certificates
containing little more than an account number (or other kind of record
locater) and public key ... if you actually wanted to do something
... it was necessary to read the information from the appropriate
record. It wasn't just large German financial institutions that had
come to this realization ... numerous financial institutions were
retrenching from the x.509 identity digital certificates of the early
90s.
Note, however, examining all the business processes that would make
use of RPO-certificates ... we were able to demonstrate that it was
trivial to include the public key in the specified account record
... which made the associated PKI and digital certificates redundant and
superfluous (since the relying party would be retrieving *all*
necessary from the appropriate record).
This also significantly influenced our work on the X9.59 financial
standard in the X9A10 financial standard working group (which in the
mid-90s had been given the requirement to preserve the integrity of
the financial infrastructure for all retail payments)
https://www.garlic.com/~lynn/x959.html#x959
It wasn't just that the RPO-certificates were redundant and
superfluous. The typical RPO-certificates being tested in that
time-frame were contributing enormous payload bloat (PKI and digital
certificate payload overhead size was on the order of one hundred times
larger than the typical financial transaction size). misc. past posts
mentioning the enormous payload bloat of redundant and superfluous
digital certificates
https://www.garlic.com/~lynn/subpubkey.html#bloat
In the same timeframe as x9a10 work on x9.59 financial standard, the
X9F committee was attempting to take another approach. They had a
financial standard work item for "compressed" digital certificates
... with the objective to try and get payload bloat of (the
redundant and superfluous) RPO-certificates and PKI overhead
bloat down to possibly only 5-10 times larger than the base financial
transaction payload size.
One of their suggested approaches ... was that all fields that were
common to an issuer's RPO-certificate would be eliminated ... i.e. only
the fields that were unique to every RPO-certificate would be
included. I had a slightly different suggestion ... instead eliminate
all fields in the RPO-certificate that the financial institution
already had on file for the entity. Since by definition, it could be
shown that the financial institution already had all fields (if
nothing else from having issued the RPO-certificate in the first
place), then it would be possible to eliminate all fields, reducing an
RPO-certificate to zero bytes.
So as an alternative to deploying a certificate-less public key
infrastructure
https://www.garlic.com/~lynn/subpubkey.html#certless
it would be possible to deploy a fully functional PKI operation that
depended on attaching zero byte digital certificates to every
transaction (which would also address the enormous PKI payload
bloat). some old posts discussing the enormous advantages of a PKI
with zero byte digital certificates
https://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
TPM, part 2
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: TPM, part 2
Date: Sun, 01 Jul 2007 19:53:40 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx, leichter_jerrold@xxxxxxxx
Peter Gutmann wrote:
I have a friend who implemented a basic trusted-boot mechanism for a student
project, so we have evidence of at least one use of a TPM for TC, and I know
some folks at IBM Research were playing with one a few years ago, so that's at
least two users so far. Anyone else?
as i've mentioned before ... we looked at somewhat similar hardware
solution (but much simpler) for the original acorn (ibm/pc code name),
primarily as software piracy countermeasure ... but the tamper
resistant technology state of the art at the time was way too
expensive ... and investigation was dropped. what was seen during the
80s were things like those specially encoded floppy disks ... that had
to be inserted when you started the application ... a couple past
posts/references:
https://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools
https://www.garlic.com/~lynn/2007m.html#20 Patents, Copyrights, Profits, Flex and Hercules
in the late 90s i would periodically chide the TPM folks about what
they were doing ... and at an assurance talk i gave in the trusted
computing track at intel developers forum (spring 2001), i chided the
guy running the effort (was sitting in the front row) that it was nice
to see that over the previous couple yrs that TPM had started to look
more & more like the AADS chip strawman. his retort was something
about it being because I didn't have a committee of couple hundred
people helping me with (my) chip design.
misc. past posts mentioning aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
To: Peter Gutmann <pgut001@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Mon, 02 Jul 2007 09:50:15 -0600
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
CC: adam@xxxxxxxx, cryptography@xxxxxxxx,
dan@xxxxxxxx, leichter_jerrold@xxxxxxxx, perry@xxxxxxxx
Peter Gutmann wrote:
Smart cards are part of the problem set, not the solution set -
they're just an expensive and awkward distraction from solving the
real problem. What I was suggesting (and have been for at least ten
years :-) is a small external single-function device (no need for an
OS) that can't be compromised by malware because there's no attack
vector for the malware to get at it.
there is an interesting side story to this involving certification,
common criteria, protection profiles, etc.
possibly the majority of the smartcard protection profiles have to do
with all the problems allowing software/application to be loaded. on
the other hand, you can get a common criteria evaluation done on the
basic chip ... w/o any application loading ... and being able to show
a much higher security level ... than might be possible with any
application actually loaded.
one of the problems i ran into getting higher than eal4+ for aads chip
strawman ... was since everything was built into the silicon at
manufacturing time, and nothing could be subsequently loaded ... all
the crypto had to also be resident in the silicon.
one of the original objectives given for the aads chip strawman was
being able to do digital signature in contactless form factor within
transit gate elapsed time requirements (very low power and very fast)
... which eventually fell to doing ec/dsa ... and i couldn't get an
protection profile definition for ec/dsa higher than eal4+. similar
chips ... w/o anything loaded had been able to get eal5+ evaluation
(or better) ... but since ec/dsa was built into the chip silicon, it
was only possible to get eal4+.
the other criteria for aads chip strawman was extremely aggressive
cost reduction; i had joked i was taking a $500 milspec part, cost
reducing by 2-3 orders of magnitude and at the same time increasing
the integrity. part of the aggressive cost reduction was choosing a
single function (something you have authentication via chip
digital signature) that could be used in a broad range of applications
... and eliminate everything else.
misc. aads
https://www.garlic.com/~lynn/x959.html#aads
other posts in this thread:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Tue, 03 Jul 2007 10:29:19 -0600
To: Adam Shostack <adam@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>,
Peter Gutmann <pgut001@xxxxxxxx>,
cryptography@xxxxxxxx, dan@xxxxxxxx, leichter_jerrold@xxxxxxxx
Adam Shostack wrote:
It may be, indeed. You're going (as Lynn pointed out in another
post) to be fighting an uphill battle against the last attempts. I
don't think smartcards (per se) are the answer. What you really
need is something like a palm pilot, with screen and input and a
reasonably trustworthy OS, along with (as you say) the appropriate
UI investment.
given the recognition of the serial port issues from the earlier,
dial-in online banking ... providing a strong motivation to transfer
responsibility for all such problems to ISPs (under the guise of
moving to the internet)
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
that even the transfer of a little bit of (this earlier serial port)
institutional knowledge, could have avoided/mitigated some of the later
smartcard reader disastrous deployments
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
However, following some of the early YES CARD deployments
https://www.garlic.com/~lynn/subintegrity.html#yescard
it appeared to be more of a case where smartcard organizations were
very narrowly focused on purely smartcard issues and ignoring
everything else (probably not receptive to any input regarding
serial port issues).
that aspect was somewhat highlighted in an very early presentation about
circumstances surrounding the YES CARD ... and there was a
somewhat uncontrolled comment from somebody in the audience do you
mean to say that they managed to spend a billion dollars to prove that
chips are less secure than magstripes?.
misc. old posts/threads mentioning the pc/sc serial port issue &
smartcard reader deployment disasters
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
https://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using POWF
a fraud is a sale, Re: The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: a fraud is a sale, Re: The bank fraud blame game
Date: Tue, 03 Jul 2007 10:48:48 -0600
To: Ed Gerck <edgerck@xxxxxxxx>
CC: nbohm@xxxxxxxx, cryptography@xxxxxxxx
Ed Gerck wrote:
Yes. Today, under current practice, there's actually a strong
incentive to keep existing fraud levels than to try to "scrub it
out" -- fraud has become a sale:
thread from earlier this year ... when over a period of a month or so
there were several releases that essentially had fraud declining by
10-15 percent simultaneously with fraud increasing by 200-300 percent.
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007m.html#65 nouns and adjectives
this followed an article pointing out that EU financial institutions
had something less than 10percent of their bottom line coming from
payment transaction operation ... while it was closer to 40percent for
US financial institutions.
https://www.garlic.com/~lynn/2007k.html#12 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#13 IBM Unionization
https://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
and articles about interchange fee represents the single largest expense
for some retail merchants
https://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#72 Free Checking
a fraud is a sale, Re: The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: a fraud is a sale, Re: The bank fraud blame game
Date: Wed, 04 Jul 2007 06:21:47 -0600
To: Ed Gerck <edgerck@xxxxxxxx>
CC: nbohm@xxxxxxxx, cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game
for a little bit more background ....
signature-debit fraud has been quoted at 15 times that of pin-debit
fraud ... some refs:
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#60 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#12 IBM Unionization
and so the merchant fees for signature-debit are like an order of
magnitude more than pin-debit (i.e. more on par with credit fees)
http://www.digitaltransactions.net/newsstory.cfm?newsid=738
http://www.digitaltransactions.net/newsstory.cfm?newsid=1251
in the US, there has been some numbers that walmart accounts for 25-30
percent of all retail store transactions. several yrs ago they won a
class action legal action against the payment transaction
infrastructure.
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
various refs:
http://www.classactionrefund.com/VisaInfo.html
http://www.inrevisacheckmastermoneyantitrustlitigation.com/history.php3
http://www.digitaltransactions.net/newsstory.cfm?newsid=623
other posts in the previous part of this thread:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Wed, 04 Jul 2007 10:43:49 -0600
To: ray@xxxxxxxx
CC: lucks@xxxxxxxx, hal@xxxxxxxx, dan@xxxxxxxx,
leichter_jerrold@xxxxxxxx, pgut001@xxxxxxxx,
cryptography@xxxxxxxx
R. Hirschfeld wrote:
During the course of the CAFE project some commercial electronic
purse systems emerged, notably Proton (from Banksys in Belgium,
replicated in other counties under other names) and Mondex. These
were in many ways less sophisticated than CAFE's system (which was
multi-issuer, multi-currency, privacy-respecting, etc.) but had
serious commercial backing. For the most part these seem to have
stagnated or died. I suspect that getting them to catch on would
require drastic measures such as:
we had gotten tasked to do a design and costing of mondex
implementation in the states (all the transaction processing
dataprocessing, sizing capacity and resources, etc) ... and looking at
pricing various kinds of mondex related transactions ("super brick"
from mondex international and how it flowed thru the rest of the
infrastructure).
the conclusion we came up with was that nearly all the financial
justification for mondex was in the float. later there were scenarios
where mondex international was encouraging deployment in various
countries by offering to split the float with the chartered mondex
national body (and then it seemed like float offerings were starting
to peculate down to financial institutions lower in the mondex
hierarchy)
then along came an EU statement that mondex (and similar
implementations) would only be given a grace period with regard to
retaining the float (as a mechanism to underwrite start-up costs)
... but after a period of 2-3 yrs, they were then going to be required
to start paying interest on balances carried in the
cards. after that, much of the interest(?) seemed to evaporate.
separately there were some issues with the chip technology being used
in the mondex cards.
misc. past posts mentioning mondex.
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aadsm18.htm#42 Payment Application Programmers Interface (API) for IOTP
https://www.garlic.com/~lynn/aadsm20.htm#7 EMV
https://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm23.htm#23 Payment systems - the explosion of 1995 is happening in 2006
https://www.garlic.com/~lynn/aadsm25.htm#31 On-card displays
https://www.garlic.com/~lynn/2002e.html#14 EMV cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002g.html#53 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2002g.html#54 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
https://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure?
https://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless)
https://www.garlic.com/~lynn/2007i.html#57 John W. Backus, 82, Fortran developer, dies
The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Wed, 04 Jul 2007 13:39:51 -0600
To: ray@xxxxxxxx
CC: lucks@xxxxxxxx, hal@xxxxxxxx, dan@xxxxxxxx,
leichter_jerrold@xxxxxxxx, pgut001@xxxxxxxx,
cryptography@xxxxxxxx
R. Hirschfeld wrote:
- differential pricing: electronic purse payments are potentially
cheaper to process than those of debit cards because they are
offline, but consumers find it more convenient to keep money in
their bank account than on a smart card and will likely continue to
do so as long as it costs no more. (This may become less of an
issue if/when all vending machines and parking meters are on the
internet anyway.)
re:
https://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game
in the mid-90s, a number of US financial institutions looked at the
economics of the EU chipcard electronic purses (modulo the float issue
... which could be made to work) the issue was that the (much more)
expensive chips were being used to offset the significantly higher PTT
costs (and/or just plain PTT availability) in Europe.
The US could deploy a magstripe authentication card for stored-value
... that did online transactions using much of the existing online
point-of-sale infrastructure ... for significantly lower overall
infrastructure costs than the EU chip-based offline stored value. The
magstripe card basically became a something you have authentication
mechanism. The primary trade-off issue was that the US telecom pricing
was so much lower than in Europe (and lots of 80s & 90s design in
europe was being driven by the extremely high PTT costs and/or, in
some cases, lack of PTT availability).
Note, however, the internet along with various telcom and technology
changes around the world have contributed to significantly changing
those online/offline economic trade-off considerations.
Independent of the online/offline economic issues ... there are some
fraud and security issues that could drive towards using chips for a
more secure something you have authentication device.
part of this was our semi-facetious statements about taking a $500
(chip) milspec part, aggresive cost reduction by 2-3 orders of
magnitude while increasing the integrity/security
https://www.garlic.com/~lynn/x959.html#aads
however, there is some lingering effects from the older high PTT costs
related to chip-based architectures ... and whether there are any
residual design features related to (originally) supporting offline
operation.
Part of this could be seen in the YES CARD exploits ... where,
transaction "business rules" were left in the chip implementation (as
oppsed to the chip being purely an authentication mechanism)
... contributing to the enormous vulnerability increase
https://www.garlic.com/~lynn/subintegrity.html#yescard
For the float issue with regard to the class of US gift/stored-value
cards ... they are sold as "merchant" cards ... i.e. the kind of gift
& stored-value cards you see used by coffee shops, video rental,
grocery stores, large department stores, etc. Possibly, in part,
because they are "merchant" cards ... as opposed to "bank" cards
... the associated accounts and balances are pretty far removed from
any jurisdiction that might impose payment of interest.
misc. past posts about how the large difference in telecom costs drove
different solutions
https://www.garlic.com/~lynn/aepay11.htm#28 Solving the problem of micropayments
https://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is *dangerous*? (was re: Fake companies, real money)
https://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002d.html#41 Why?
https://www.garlic.com/~lynn/2002e.html#22 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2003h.html#54 Smartcards and devices
https://www.garlic.com/~lynn/2004j.html#39 Methods of payment
https://www.garlic.com/~lynn/2004j.html#43 Methods of payment
https://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
a fraud is a sale, Re: The bank fraud blame game
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: a fraud is a sale, Re: The bank fraud blame game
Date: Mon, 09 Jul 2007 16:55:12 -0400
To: Ed Gerck <edgerck@xxxxxxxx>
CC: nbohm@xxxxxxxx, cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game
recent item with the other side of the issue (as opposed to being able
to profit when merchants have fraud)
Data Security Advanced by New Aleratec Multi-purpose DVD/CD Shredder
http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=12940
from above:
Identity Theft and Fraud cost business $600 billion a year, according
to the Association of Certified Fraud Examiners.
.. snip ...
post from earlier this spring about series of articles essentially
appearing simultaneously:
https://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
ID fraud down, except credit cards
http://www.pcadvisor.co.uk/news/index.cfm?newsid=8280
Survey: ID fraud in U.S. falls by $6.4B
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9010082&aintsrc=hm_list
Survey Indicates ID Theft May Be Diminishing
http://yro.slashdot.org/yro/07/02/01/2127224.shtml
Study: ID fraud in decline
http://www.securityfocus.com/brief/423
US ID theft losses decline
http://www.astalavista.com/?section=news&cmd=details&newsid=3376
US ID theft losses decline
http://www.theregister.com/2007/02/05/us_id_fraud_survey/
and
ID Theft Is Exploding In The U.S.
http://www.informationweek.com/news/showArticle.jhtml?articleID=198701579
ID fraud soaring across the pond
http://www.silicon.com/financialservices/0,3800010322,39166236,00.htm
Threatwatch: how much to MITM, how quickly, how much lost
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 23, 2007 10:23 PM
Subject: Threatwatch: how much to MITM, how quickly, how much lost
Blog: Financial Cryptography
https://financialcryptography.com/mt/archives/000941.html
re:
https://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game
https://www.garlic.com/~lynn/2007n.html#72 Poll: oldest computer thing you still use
and
Identity theft has replaced drug dealing as No. 1 crime in the
U.S. And thieves often aren't caught.
http://www.pennlive.com/news/expresstimes/index.ssf?/base/news-5/1185077364273960.xml&coll=2
Identity theft soars to top of modern crime list
http://www.gatewaynewspapers.com/signalitem/focus/84274/
Threatwatch: how much to MITM, how quickly, how much lost
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 24, 2007 08:21 PM
Subject: Threatwatch: how much to MITM, how quickly, how much lost
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#44 Threatwatch: how much to MITM, how quickly, how much lost
from posting in thread in crypto mailing list
https://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game
one of the references mentioned in the above:
Data Security Advanced by New Aleratec Multi-purpose DVD/CD Shredder
http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=12940
from above:
Identity Theft and Fraud cost business $600 billion a year, according
to the Association of Certified Fraud Examiners.
... snip ...
A year or two ago i tripped across an obscure study that quoted a
similar number ... this was after there was some news coverage of a
talk that happened to mention cybercrime being greater
the crypto mailing list post also references a number of different
news articles running somewhat concurrently earlier this spring
... one series was that id-fraud was in decline and the other series
was that id-fraud was exploding.
and series of news articles from late 2005:
Cybercrime Profits Outpace Drug Trafficking
http://www.ecommercetimes.com/story/47559.html
Expert: Cyber-crime Yields More Cash than Drugs
http://www.eweek.com/article2/0,1895,1893592,00.asp
Expert: Cyber-crime Yields More Cash than Drugs
http://www.extremetech.com/article2/0,1697,1893916,00.asp
Cybercrime now outstrips drug trafficking
http://www.cw360asp.com/Articles/2005/11/29/213190/Cybercrimenowoutstripsdrugtrafficking.htm
Cybercrime 'more lucrative' than drugs
http://www.theregister.co.uk/2005/11/29/cybercrime/
Cybercrime profits exceed those of drugs, expert says
http://www.globetechnology.com/servlet/ArticleNews/TPStory/LAC/20051129/RTICKERB29-2/TPTechnology/
Cybercrime more profitable than illicit drug sales?
http://arstechnica.com/news.ars/post/20051129-5648.html
Threatwatch: how much to MITM, how quickly, how much lost
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 26, 2007 06:52 PM
Subject: Threatwatch: how much to MITM, how quickly, how much lost
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#44 Threatwatch: how much to MITM, how quickly, how much lost
https://www.garlic.com/~lynn/aadsm27.htm#45 Threatwatch: how much to MITM, how quickly, how much lost
following is quite a bit less than amount quoted a couple yrs ago
... on the other hand, this report comments that there may some
incentive that leads to significant underreporting
Cybercrime Costs US Economy at Least $117B Each Year
http://www.technewsworld.com/story/58517.html
Cybercrime Costs US Economy at Least $117B Each Year
http://www.ecommercetimes.com/story/58517.html
from above:
"Whatever is reported by organizations, most of that will likely be
underreported because of disincentives to report losses," he told
TechNewsWorld.
Reporting remains a major challenge to fighting cybercrime, Powner
noted.
... snip ...
If your CSO lacks an MBA, fire one of you
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 26, 2007 07:18 PM
Subject: If your CSO lacks an MBA, fire one of you
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000940.html
"security" isn't just limited to things like defenses and
countermeasures against attacks and fraud ... security supposedly
includes things like assurance, availability, correctness, etc.
there was a recent thread in mainframe discussion about the general
issue of "quality" (and somewhat the related costs).
https://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
https://www.garlic.com/~lynn/2007n.html#77 PSI MIPS
https://www.garlic.com/~lynn/2007n.html#79 PSI MIPS
i've mentioned before that we were called in to consult with small
client/server startup that wanted to do financial transactions on
their server (frequently now referred to as electronic commerce)
misc. past references
https://www.garlic.com/~lynn/subnetwork.html#gateway
the startup had this technology they called SSL that they wanted to
use in conjunction with the financial transactions. some misc. past
references
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
and some comments about general state of domain name certification and
related PKI operation
https://www.garlic.com/~lynn/subpubkey.html#catch22
however, as noted in the referenced thread (somewhat on general
quality issues and related costs) ... a lot of what we did related to
server financial transactions drew on having earlier done ha/cmp
product
https://www.garlic.com/~lynn/subtopic.html#hacmp
which included some very detailed vulnerability studies (which were
not limited to just attack & fraud defenses and countermeasures)
If your CSO lacks an MBA, fire one of you
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 27, 2007 07:45 AM
Subject: If your CSO lacks an MBA, fire one of you
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you
the previous post and references allude to higher quality
implementations costing more ... and frequently there have been
direction to go for lowering costs without a whole lot of attention to
what happens to the costs (and security, integrity, assurance, etc).
there was also a passing reference to mainframe operation having some
feature/function that actually lower the total cost of achieving
higher quality implementations.
the other place that this shows up in has to do with the effects that
some of the tools and building blocks have on overall quality,
security, integrity, assurance, etc.
for instance in these posts mentioning buffer overflow (and associated
exploits/vulnerabilities)
https://www.garlic.com/~lynn/subintegrity.html#overflow
... there is a repeated assertion that a lot of it is due to the use
of C programming language ... that implementations done in some other
languages have drastically lower occurance of overflow-related
exploits/vulnerabilities. for instance, these posts reference a
security evaluation of multics (implemented in pli) that found no
overflow exploits/vulnerabilities
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
also, these posts mention initial mainframe tcp/ip product being
implemented in vs/pascal ... which also had no buffer overflow
exploits/vulnerabilities (that i know of). however there were
performance issues in the initial implementation ... however i had
done the rfc 1044 implementation which achieved about 25 times the
thruput in about 1/20th-1/30th the pathlength (around three orders of
magnitude improvement)
https://www.garlic.com/~lynn/subnetwork.html#1044
another reference to attempting to improve the assurance/integrity of
the building blocks is having done a one week JAD looking at what
could be done in Taligent infrastructure to significantly improve the
quality of the resulting applications (taligent was an object oriented
programming environment ... somewhat an outgrowth of apple's attempt
at an object oriented operating system, pink)
https://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#38 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
the original references have passing mention of it frequently taking
4-10 times the original application implementation effort to support
business critical application. somewhat related is common observation
that doing a "2167A" implementation takes ten times the effort as what
it frequently takes to do many common implementations. similar to the
taligent JAD, we looked at what software infrastructure changes would
be necessary to reduce the cost of 2167A implementation from ten times
to only two times. a few past posts mentioning 2167A:
https://www.garlic.com/~lynn/2001i.html#55 Computer security: The Future
https://www.garlic.com/~lynn/2002e.html#70 Computers in Science Fiction
https://www.garlic.com/~lynn/2004q.html#1 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
https://www.garlic.com/~lynn/2006.html#37 The new High Assurance SSL Certificates
https://www.garlic.com/~lynn/2006q.html#40 Was FORTRAN buggy?
for other random drift ... reference to giving keynote at nasa high
dependability computing consortium workshop:
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html
If your CSO lacks an MBA, fire one of you
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 27, 2007 01:25 PM
Subject: If your CSO lacks an MBA, fire one of you
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you
https://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
long ago and far away, shortly after graduation and going to work for
a large computer vendor ... they hired a new CSO ... who had come from
a fairly high ranking gov. position.
This was back in the days before there was much computer security and
large corporations frequently hired former gov. employees who's
background were various kinds of physical security; actually this
continues to frequently happen and then they might have a separate
CSIO position
For whatever reason, I got assigned to run around with the new CSO for
several months ... imparting some information about electronic kind of
security and having a little physical security details rub off.
If your CSO lacks an MBA, fire one of you
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 28, 2007 01:54 PM
Subject: If your CSO lacks an MBA, fire one of you
Blog: Financial Cryptography
i replied:
>Hey Lynn,
>What is JAD?
>
>What's a 2167A :)
joint application development .... sort of a high-powered design
session ... frequently have a person specialized in facilitating
meetings/results running a jad ... wiki reference:
https://en.wikipedia.org/wiki/Joint_application_development
....
here is picture of various processes ... including 2167A ... and
somewhat how they are related:
http://www.stsc.hill.af.mil/crosstalk/1997/09/frameworks.asp
more detail
http://www2.umassd.edu/SWPI/DOD/MIL-STD-2167A/DOD2167A.html
wiki reference
https://en.wikipedia.org/wiki/DOD-STD-2167A
... snip ...
re:
https://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you
https://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
https://www.garlic.com/~lynn/aadsm27.htm#49 If your CSO lacks an MBA, fire one of you
it isn't just cso ... here is a number of posts discussing a major
security failure in the financial industry. it was a bunch of techies
that eventually spent truely huge amounts of money on attempted
wide-spread deployments that met with disastrous results. the
disastrous failures of the deployments resulted in a wide-spread
opinion in the financial industry that hardware tokens (for
authentication and security) weren't viable in the consumer market
segment.
the funny thing was that the seeds for the disastrous failures had
been known in the financial industry for several years ... just in
different parts of the organization i.e. for whatever reason, those
responsible for the disastrous failures weren't able to draw on the
institutional knowledge from earlier activities.
there is the old saying about those that don't study history are
doomed to repeat the same mistakes.
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
https://www.garlic.com/~lynn/2007n.html#60 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#63 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#65 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#66 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#75 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#78 Poll: oldest computer thing you still use
now while the direct costs of the disastrous deployments were
significant, the 2nd order costs are quite a bit greater ... i.e. the
dampening effect on deployment of effective authentication and
security infrastructures leaves open large vulnerabilities and
threats
https://www.garlic.com/~lynn/aadsm27.htm#44 Threatwatch: how much to MITM, how quickly, how much lost
https://www.garlic.com/~lynn/aadsm27.htm#45 Threatwatch: how much to MITM, how quickly, how much lost
https://www.garlic.com/~lynn/aadsm27.htm#46 Threatwatch: how much to MITM, how quickly, how much lost
there may also be some x-over here with recent article on the success
of failure
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/aadsm26.htm#59 On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?
that with fundamental systemic flaws, industries can grow up that make
a long-term business out of continuous fixing and patching ... aka
like that systemic flaws found in the C language programming
environment mentioned earlier in this thread:
https://www.garlic.com/~lynn/subintegrity.html#overflow
or the fundamental systemic flaws in the "naked transaction" paradigm
https://www.garlic.com/~lynn/subintegrity.html#payment
disclaimers:
... as mentioned earlier, we had done detailed vulnerability and
threat analysis in the 80s, as part of doing ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
the knowledge contributed quite a bit when we were called in to
consult with small client/server startup that wanted to do payments on
its server (they had this technology they called SSL, and the effort
is now frequently referred to as electronic commerce)
https://www.garlic.com/~lynn/subnetwork.html#gateway
then in the mid-90s, the x9a10 financial standards working group had
been given requirement to preserve the integrity of the financial
infrastructure for all retail payments ... there were further detailed
vulnerability and threat analysis (and we were able to also draw
heavily on previous experience with ha/cmp and the original electronic
commerce effort)
https://www.garlic.com/~lynn/x959.html#x959
it was in this period that we spent some amount of time on design of
authentication hardware token with both extremely aggressive cost
reduction and security improvement. it was some of the these other
deployment disasters that also had downside impact on the aads chip
strawman
https://www.garlic.com/~lynn/x959.html#aads
we somewhat facetiously claimed that we were doing 2-3 order
aggressive cost reduction on $500 mil-spec part ... while at the same
time improving the security & integrity.
we also somewhat facetiously claimed that the per chip aggressive cost
reduction and the work on person-centric hardware token paradigm could
represent an overall four order of magnitude cost reduction on an
extensively deployed hardware token authentication
infrastructure. misc. past posts mentioning institutional-centric
hardware token paradigm vis-a-vis a person-centric hardware token
paradigm
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as a debate topic
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#43 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007m.html#27 nouns and adjectives
https://www.garlic.com/~lynn/2007m.html#31 nouns and adjectives
Know Your Enemy: Scott McNeally on security theater
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 28, 2007 08:32 PM
Subject: Know Your Enemy: Scott McNeally on security theater
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000942.html
grump, grump ... i have plethora of past posts on subject of confusing
authentication and identification.
authentication is about making sure only the authorized entities are
allowed ... frequently associated with preventing fraud and/or other
kinds of bad things
identification is frequently about catching the entities responsible
after something bad has happened.
we have frequently asserted that x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
is privacy agnostic ... providing infrastructure for strong
authentication as countermeasure to fraudulent transactions ... w/o
requiring identification.
https://www.garlic.com/~lynn/subpubkey.html#privacy
this is from the mid-90s and hey day of some of many privacy
efforts. lots of institutions were starting to realize that the x.509
identity digital certificates represented enormous privacy and
liability problems.
apparently having been convinced that digital certificates carried
some magical properties ... there was retrenchment to
relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
only carrying some sort of record/account locator ... where the
necessary information to complete transactions was actually
kept. however, we were repeatedly able to trivially demonstrate that
the actual digital certificates were redundant and superfluous ... and
digital signature authentication business processes would continue to
work just fine if the digital certificates were totally ignored
https://www.garlic.com/~lynn/subpubkey.html#certless
To large extent, many of the identification cards efforts ... are the
x.509 identity digital certificates (from the early 90s), reborn with
hardware token wrappers.
and the reference in long winded post in related thread
https://financialcryptography.com/mt/archives/000940.html
... also archived here
https://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
that includes some discussion about some past attempts at hardware
token deployments.
In the mid-90s time-frame part of x9.59 work was influenced by EU-DPD
which had spawned a statement that electronic payments at
point-of-sale should be as anonymous as cash. This led to the
observation that would include removing names from various payment
(debit, credit, etc) cards ... requiring a transition away from
identification to authentication.
In the x9.59 case, it was shown that appropriate gov. agencies could
still follow due process and locate individuals associated with
transactions ... but the authentication paradigm wouldn't require that
identification was publicly brandished about as part of every
transaction.
for other drift, we also were involved in co-author of x9.99 financial
industry standard involving privacy ... some reference here ... since
as part of the effort, did a "privacy" merged taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote
in a manor similar to the other merged taxonomies and glossaries
more on firing your MBA-less CSO
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 30, 2007 08:14 PM
Subject: more on firing your MBA-less CSO
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000943.html
note that in the naked transaction thread
https://www.garlic.com/~lynn/subintegrity.html#payment
... the discussion was that there are hundreds and thousands of places
that card transaction details might leak ... including (but not
limited to) past studies that possibly seventy percent of such
leakages involve *insiders*. given the enormous number of leakage
points, the naked transaction thread discussed armoring the actual
transaction so that any leaked information became useless to crooks
(i.e. the "card transaction" details could fall into the wrong hands,
but they would find the information useless) ... ala what was
specified for the x9.59 financial transaction standard
https://www.garlic.com/~lynn/x959.html#x959
i.e. in the mid-90s the x9a10 financial standard working group had
been given the requirement to preserve the integrity of the financial
infrastructure for all retail payments
https://www.garlic.com/~lynn/subpubkey.html#x959
as to the recent disastrous reader deployment references:
https://www.garlic.com/~lynn/aadsm27.htm#49 If your CSO lacks an MBA, fire one of you
https://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
note that there have been a efforts that aren't particularly
CSO-related ... just techies ... in relatively the same time frame as
the disastrous card reader deployments ... there were also some
magnificent other disastrous security attempts in portions of the
financial market segment.
in about the same time frame as disastrous reader deployments, there
were some number of YES CARD deployments ... some discussion here
https://www.garlic.com/~lynn/subintegrity.html#yescard
the YES CARD scenario should have been evident to anybody familiar
with skimming attacks (dating back at least a decade or so earlier)
also leading up to time frame of the disastrous reader deployments,
there were still some lingering belief in the "magical" properties of
digital certificates and misc. related pilot projects that came in at
the $50mil range. the certification authority industry were making all
sorts of offers to the financial community (for scale-up roll-out
after the pilot stage), if the financial institution would register a
public key for each account in the master file ... and then provide a
certification authority a copy of that master file ... then each
account record would be magically transposed into a digital
certificate at only $100 a pop per annum. This appeared to be
acceptable to the techy community, until executives of some of the
larger institutions (i.e. 10million or more accounts) started tallying
the annual payments to certification authorities and shutdown the
projects.
this doesn't even need to take into the consideration that the digital
certificates themselves would be redundant and superfluous ... posts
about relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
and certificate-less digital signatures
https://www.garlic.com/~lynn/subpubkey.html#certless
a combination of the disastrous reader deployments, the ridiculous
(projected) costs of the digital certificate (scale-up) efforts, the
YES CARDS and misc. other activities ... contributed to financial
insitution risk managers and executives starting to seriously question
the competency of "techies" (not particularly a CSO or CSIO issue).
the aggregate effect was (also) significant damper on being able to
deploy any reasonable authentication and security technologies.
misc. past posts discussing the $100/account/annum proposition
(minimum cost to the financial industry $20b/annum assuming only a
single account/person ... again independent of the issue of whether
the digital certificates were redundant and superfluous)
https://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
https://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/2005o.html#2 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
https://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies
Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 6, 2007 09:51 AM
Subject: Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000947.html
way back when ... it was about designing & implementing
systems/infrastructure to prevent bad things happening. some slight
(nearly 40yr old) drift:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
now we have a lot of systems/infrastructures where it is all about
attempting to recognize when bad things have happened ... and the
basic systems/infrastructures are effectively recognized as extremely
vulnerable ... and solutions are effectively done in terms of bailing
wire and chewing gum. (one might be tempted to say that things have
severely regressed and there is little lore left anymore about
prevention)
recent reference:
https://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
old buffer overrun post
https://www.garlic.com/~lynn/2005d.html#55 Buffer overruns
with these references
Microsoft Researchers Target Worms, Buffer Overruns
http://www.neowin.net/comments.php?id=27321&category=main
Microsoft researchers target worms, buffer overruns
http://www.infoworld.com/article/05/03/03HNmicrosoftworms_1.html
Microsoft Researchers Target Worms, Buffer Overruns
http://www.pcworld.com/news/article/0,aid,119891,00.asp
or this old post:
https://www.garlic.com/~lynn/2000.html#25 Computer of the century
with reference to discussion of how to deal with some number of
C-language related coding problems .... 90% of which wouldn't happen
in various other programming languages.
passing reference at a assurance panel in 2001 to comment about m'soft
holding up windows 2000
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
I remember in the early 80s ... where state-of-the-art had progressed
to the point where work was going on ... not with regard to outsider
attacks or straight-forward insider attacks (supposedly still
responsible for up to 70percent of the fraud) ... but the
state-of-the-art was collusion countermeasures .... i.e. organized
groups of insiders attempting to bypass provisions preventing insiders
from subverting the systems.
misc. past posts mentioning that early 80s security state-of-the-art
focusing on insider collusion (i.e. having procedures in place for
outsider attacks and the simple, straight-forward insider attacks)
https://www.garlic.com/~lynn/aadsm3.htm#kiss10 KISS for PKIX. (authentication/authorization seperation)
https://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm11.htm#10 Federated Identity Management: Sorting out the possibilities
https://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
https://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
https://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#40 Interesting bit of a quote
https://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005g.html#37 MVS secure configuration standard
https://www.garlic.com/~lynn/2005g.html#38 MVS secure configuration standard
https://www.garlic.com/~lynn/2005k.html#1 More on garbage
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006d.html#30 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#33 Password Complexity
https://www.garlic.com/~lynn/2006n.html#32 The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2007f.html#39 Silly beginner questions
Security can only be message-based?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 7, 2007 03:54 PM
Subject: Security can only be message-based?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000949.html
i would put it slightly differently, KISS api with strongly enforced
boundaries and partitioning.
message-passing tends to imply various kinds of partitioning.
however, there was a lot done in the 60s (disclaimer, i was involved)
with virtual machine paradigm as a partitioning mechanism ... with
message-passing between the virtual machines.
this was work at the cambridge science center ... 4th flr, 545 tech
sq.
https://www.garlic.com/~lynn/subtopic.html#545tech
which traces some of its heritage back to CTSS. recent mention of
upcoming 40th anniversary of (cp67, as well as 35th anniversary of
vm370) product announce
https://www.garlic.com/~lynn/2007n.html#92
also reference to archeology in this recent post
https://www.garlic.com/~lynn/aadsm27.htm#47 Doom and Gloom spreads, security revision suggests "H6.5: Be an adept!"
and this reference
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
Of course, Multics on the 5th flr, also traces back to CTSS, recent
post mentioning multics
https://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
the science center was also responsible for the technology for the
internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
which was larger than arpanet/internet from just about the beginning
until sometime mid-85.
also gml (precursor to sgml, html, xml, etc) was invented at the
science center in '69
https://www.garlic.com/~lynn/submain.html#sgml
for other historical reference .... the compare&swap instruction was
invented by CAS at the science center (note that mnemonic for
compare&swap instruction are charlie's initials) as part of work on
fine-grain multiprocessor serialization related to cp67. With some
difficulty managed to get CAS added to the 370 architecture in the
early 70s ... lots of past postings on multiprocessor support and/or
compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp
for lots & lots of historical drift ... the original sql/relational
work was implemented in virtual machine (vm370) environment at SJR
... lots of past posts mentioning system/r
https://www.garlic.com/~lynn/submain.html#systemr
some amount of the AADS work drew on background
https://www.garlic.com/~lynn/x959.html#aads
having done operating concurrency/integrity with cp67 and vm370
... but also with system/r. Also as part of doing the
high-availability product
https://www.garlic.com/~lynn/subtopic.html#hacmp
we had to work out loads of failure modes ... not just security
related ones ... and provide for correct operation in distributed
environment. if fact, during the ha/cmp work we had coined the terms
disaster survivability and geographic survivability
https://www.garlic.com/~lynn/submain.html#available
another influence was having to do the distributed lock manager for
distributed scale-up operation; some old references in this series of
old email
https://www.garlic.com/~lynn/lhwemail.html#medusa
as frequently mentioned ... we were later called in to consult for a
small client/server startup that wanted to do payment transactions on
their server ... which then required this thing called a payment
gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway
and two of the people that were responsible for what they were calling
a commerce server had earlier worked with us on distributed database
transaction scale-up ... and, in fact, were at the meeting mentioned in
these posts
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
that whole sequence of having done mainframe multiprocessor scale-up
and concurrency, database concurrency and scale-up, distributed
database operation and scale-up ... and then having done the
availability product before working on what has since come to be
called electronic commerce ... also influenced the later work on AADS.
Microsoft asserts itself as an uber-CA
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 7, 2007 09:36 PM
Subject: Microsoft asserts itself as an uber-CA
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000945.html
another way of looking at it ... is that in some cases, the browser
vendors have charged CAs quite a bit of money to get their
(self-signed) certificate included in the browser.
These aren't x.509 identity digital certificates in the traditional
sense ... these tend to be self-signed digital certificates ... which
turn out to be a convenient packaging technique for public keys that
are to be included in a trusted repository (of public keys) ... aka
rather than these digital certificates being a trust mechanism
... these kinds of digital certificates are purely public key
packaging mechanism ... and the act of including the public key in the
(browser's) trusted repository of public keys is the trust mechanism.
Now the certification authorities (CA), who have typically paid money
to have their public key included in the browser's repository of
trusted public keys, ... can turn around and charge their clients
money for digitally signed (trust) digital certificates (verifiable by
one of the public keys included in a browser's repository of trusted
public keys).
So the ability to remove a (certification authorities) public key from
a browser's repository of trusted public keys ... might also be
interpreted as impacting a whole economic ecosystem (since the CA's
clients stop receiving benefit from having the certificates, they paid
for, being accepting ... which in turn impacts the economic operation
of the CA that had paid money to have their public key included in the
browser's trusted public key repository).
Having the browser vendor automatically reload public keys into the
browser's repository of public keys ... might be construed as the
browser vendor actually maintaining the master copy of trusted public
keys (which they probably have charged quite a bit of money to include
a public key) ... and any specific browser's copy is purely a "local"
cache. While it might superficially appear that a browser's local copy
of trusted public keys is purely autonomous ... protocols implemented
by the browser software could actually manage cache consistency with
the vendor's master copy. In theory, not only could a cache
consistency algorithm reload trusted public keys that have been
deleted from the local cache ... but might also load new public keys
that had never been in a local cache. Such an hypothetical cache
consistency implementation could also do away with any certificate
revocation kludge for certification authority public keys (we've made
past claims that our repeated criticism of certificate revocation
operation led to the OCSP effort).
In any case, the whole public key reload effort might possibly be a
browser vendor, certification authority, CA-client economic ecosystem
... having little or nothing to do directly with PKI relying parties.
This is orthogonal to the traditional trusted 3rd party certification
authority having no real business foundation ... aka the relying party
typically doesn't have any sort of contractual relationship or other
mechanism on which to base liability and/or recourse with regard to
anything done by the certification authority.
This is somewhat highlighted by the federal PKI operation where the
GSA (as agent for federal gov. relying parties) has contracts with the
various approved certification authorities (creating a basis for legal
reliance between the relying parties and the certifying
operations). These "contracts" bridge the legal and contractual gap
with regard to reliance that occurs in many of the deployed PKI
operations
misc. past posts mentioning the contractual work around in the federal
PKI to the typical trusted 3rd party kludge:
https://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
https://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
https://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#6 John W. Backus, 82, Fortran developer, dies
The Uneasy Ride on the Cryptography Bandwaggon
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 10, 2007 11:25 AM
Subject: The Uneasy Ride on the Cryptography Bandwaggon
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000955.html
Two guys credited with ecc in 1985 were Koblitz at univ. wash and
Victor Miller at ykt (math dept). Coppersmith (lucifer, des) was also
in the math dept at ykt.
During period that Koblitz and Miller were doing the ecc related work,
i had offices in bldg. 28 (sjr) and bldg. 29 (vlsi lab) on the west
coast ... but reported to ykt on the east coast ... which met x-cntry
flts a couple times or more a month and interacted. i had interactions
the people in the math dept (coppersmith, miller, etc) on various
crypto stuff i was doing.
misc references:
http://www.iacr.org/conferences/eurocrypt2007/slides/s14t1.pdf
http://www.certicom.com/index.php?action=ecc,home
http://www.certicom.jp/index.php?action=ecc_tutorial,ecc_tut_1_0
http://searchsecurity.techtarget.com/sDefinition/0,290660,sid14_gci784941,00.html
misc. old email related to various kinds of crypto
https://www.garlic.com/~lynn/lhwemail.html#crypto
The fundamental _barrier to entry_ in the business of payment systems
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 10, 2007 11:25 AM
Subject: The fundamental _barrier to entry_ in the business of payment systems
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000948.html
one of the big infrastructure issues in the 70s was interchange and
the associations. before that both the merchant and consumer had to be
with the same institution. this was not just a technology interconnect
problem but also contractual and legal issuef. the value-added
networks to address the interconnect problem have somewhat been
obsoleted with the growth of the global internet. however, the legal
and contractual issues still remain.
for instance, in some countries, at least in the late 90s, and
possibly still true today, required bilaterial, contractual agreements
between every accepting merchant and every issuing consumer
institution.
the associations allowed merchants to have (contractual) agreements
with their financial institutions, consumers have (contractual)
agreements with their financial institutions. then all financial
institutions have contractual agreements with the associations (as
opposed to every individual financial institution required to have
bilaterial contract with every other financial institution) This
reduced N*M problem to a N+M ... aka N are number of merchant
financial institutions and M are number of consumer financial
institutions (with each on the order of tens of thousands)
old posts discussing the N*M issue:
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
the issue of interchange/association (or lack there-of) also reared
its head in the digicash trials ... being limited to a single, common
institution that served both the merchants and the consumers.
disclaimer ... in the digicash liquidation ... we were called in to
evaluate the patent portfolio.
On the downside of the MBA-equiped CSO
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 28, 2007 09:02 AM
Subject: On the downside of the MBA-equiped CSO...
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000944.html
for some unrelated historical perspective, in silicon valley, starting
at least in the early 80s ... individuals with any kind of engineering
or technical degree plus an MBA would command a large premium. however
this was about the time that MBAs (and accountants) were starting to
be blamed for ruining american business (attributed for the fanatical,
total focus on quarterly numbers). this was also about the time i
sponsored john boyd for some corporate briefings. he attributed much
of the ruining of american business on the training that many
corporate executives received as young officers in the early days of
WW2. lots of past posts mentioning john boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
some of the smartcard issues were that there were various special
interests that viewed some part or another of the activity as profit
opportunity (as opposed to purely cost issue). in a past life, we had
been indoctrinated with "walking" the complete end-to-end process as
part of identifying cost-saving opportunities.
as to the smartcard reader disaster, i had noted that part of this was
one area of the organization not communicating to another part of the
organization. the consumer smartcard reader disasters had to do with
problem supporting serial port interface. this had been identified by
home banking operations (from the days of serial port modems) as a
major excuse to migrate home banking to the internet in the mid-90s.
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
https://www.garlic.com/~lynn/2007n.html#60 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#63 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#65 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#66 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#75 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#78 Poll: oldest computer thing you still use
Threatwatch - more data on cost of your identity
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 10, 2007 08:29 AM
Subject: Threatwatch - more data on cost of your identity
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000969.html
one possible scenario accounting for difference between fraud value of
credit cards and identification cards is that credit cards have had a
primarily online infrastructure where each use is tracked and
recorded ... and can be "deactivated". identification cards have
tended to be offline infrastructure where use and activity haven't
tended to involve online operations with each use being tracked and
recorded and there tends to not be an easy online deactivation.
in that sense the credit card would be considered only a very small
feature of a more extensive online operation ... where identification
cards are typically operate independent of a much more extensive
infrastructure. Another view point is a credit card (as part of an
online infrastructure) tends to be purely authentication and any
authorization is embodied in the online infrastructure. identification
cards would not only represent authentication, but in an offline
paradigm, would implicitly carry the sense of authorization.
something similar can be cited for past discussion of YES CARD vulnerability
https://www.garlic.com/~lynn/subintegrity.html#yescard
and/or even PKI .... which i've repeatedly claimed had design point
trade-off for the offline email operation of the early 80s and/or
letters of credit/introduction from sailing ship days. the
"credentials" represented a "better than nothing" solution in a purely
offline environment where the relying party had access to no other
information regarding the other party (first time interaction with
complete stranger) that they were dealing with. Given any online
infrastructure and/or any sort of timely interaction with responsible
authority, the "better than nothing" solution (designed for the
offline environment) becomes a very poor substitute (tended to migrate
to purely no-value operations).
lots of past posts about mentioning "offline solutions" becoming
limited to no-value applications when higher quality "online
solutions" are available as an alternative
https://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
https://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt
https://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
https://www.garlic.com/~lynn/aadsm16.htm#22 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
https://www.garlic.com/~lynn/aadsm19.htm#8 GeoTrust says existing PKI practices are worthless
https://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
https://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
https://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL ... addenda
https://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
https://www.garlic.com/~lynn/aadsm26.htm#41 PKI: The terrorists' secret weapon (part II)
https://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as a debate topic
https://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?
https://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
https://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
https://www.garlic.com/~lynn/2004b.html#25 Who is the most likely to use PK?
https://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
https://www.garlic.com/~lynn/2004e.html#20 Soft signatures
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/2005e.html#62 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#24 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005k.html#29 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#11 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#33 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
https://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#28 confidence in CA
https://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2007g.html#30 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits?
Retailers try to push data responsibilities back to banks
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Retailers try to push data responsibilities back to banks
Date: Fri, 05 Oct 2007 18:13:36 -0400
To: cryptography@xxxxxxxx
some number of other recent notes on the subject:
Customer Service: Consumer Confidence at Stake in Retail, Credit Card
Industry Clash
http://www.ecommercetimes.com/story/59670.html
Retailer PCI Rebellion: 'No More Storing Credit Card Numbers'
http://www.darkreading.com/document.asp?doc_id=135602
Retailers Fighting To No Longer Store Credit Data
http://it.slashdot.org/it/07/10/05/192250.shtml
Retail group takes a swipe at PCI
http://www.infoworld.com/article/07/10/05/Retail-group-takes-a-swipe-at-PCI_1.html
Retailers Challenge the Networks' Card-Data Storage Requirements
http://www.digitaltransactions.net/newsstory.cfm?newsid=1536
NRF to Credit Card Companies: Stop Forcing Retailers to Store Credit Card Data
http://www.nrf.com/modules.php?name=News&op=viewlive&sp_id=380
Retail group takes a swipe at PCI, puts card companies 'on notice'
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9040958&taxonomyId=17
Rethinking the Assumptions Behind PCI-DSS
http://www.paymentsnews.com/2007/10/rethinking-the-.html
PCI Is Here: Keeping the barbarians outside the cyber gates
http://www.practicalecommerce.com/articles/580/Caveat-Vendor-PCI-Is-Here/
Retailers, Credit Card Industry Clash
http://www.physorg.com/news111253284.html
....
we had been called in to consult with this small client/server startup
that wanted to do payment transactions. this required some amount of
translating technology into business critical dataprocessing
... which has somewhat come to be referred to as "electronic
commerce". This including technology invention that they called SSL
... and among other things we had to do some detailed audits of these
supporting infrastructures that were calling themselves certification
authorities ... various past posts on the subject
https://www.garlic.com/~lynn/subnetwork.html#gateway
in the mid-90s we got involved in the x9a10 financial standard working
group that had been given the requirement to preserve the integrity of
the financial infrastructure for all retail payments. we drew on our
experience having previously done "electronic commerce" as well as
some detailed vulnerability studies and threat models. having been
given the requirement for all retail payments ... we had to look at a
standard that was lightweight enuf that could be easily deployed in
both point-of-sale as well as internet environments ... and provide
end-to-end security and integrity with countermeasures for both
"data-in-flight" vulnerabilities (aka transaction transmission) as
well as "data-at-rest" vulnerabilities (aka transaction logs and
databases). part of the issue was some studies that claimed as much
as 70 percent of ("data-in-flight" and "data-at-rest") compromises
involved "insiders" (aka countermeasures had to recognize that
majority of compromises possibly involved individuals with legitimate
access to the information).
the resulting financial standard was x9.59
https://www.garlic.com/~lynn/x959.html#x959
the x9.59 approach was to eliminate fraudulent transactions resulting
evesdropping and data breach compromises ... aka it didn't eliminate
evesdropping and data breach compromises ... but it eliminated the
ability of attackers (insiders or outsiders) to use the information
that they had obtained for purposes of doing fraudulent transactions.
Linus: Security is "people wanking around with their opinions"
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Linus: Security is "people wanking around with their opinions"
Date: Sun, 07 Oct 2007 13:20:21 -0400
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
Peter Gutmann wrote:
For people who don't read LKML (or get interesting bits forwarded to them),
there's a wonderful quote by Linus Torvalds about the difference between OS
scheduler design and security design:
"Schedulers can be objectively tested. There's this thing called
'performance', that can generally be quantified on a load basis."
"Yes, you can have crazy ideas in both schedulers and security. Yes, you can
simplify both for a particular load. Yes, you can make mistakes in both. But
the *discussion* on security seems to never get down to real numbers. So the
difference between them is simple: one is 'hard science'. The other one is
'people wanking around with their opinions'."
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/1/326534
most schedulers tend to be relatively static ... tended to have
repeatably, predictable response. one of the things that i worked on
as an undergraduate in the 60s ... was dynamic, adaptive, resource
management and being able to schedule to the bottlneck, dynamically
(which later influenced some of my opinions on adaptive security
infrastructures).
https://www.garlic.com/~lynn/subtopic.html#fairshare
some of the work was released in products while i was still an
undergraduate ... and then dropped ... nearly a decade later, i was
offered opportunity to reship dynamic adaptive resource management
infrastructure. as part of that effort, a automated, adaptive
benchmarking infrastructure was built ... and in the final sequence,
2000 benchmarks were involved, taking three months elapsed time ... as
part of both calibrating and validating the resource management
capability across a broad range of workloads and configurations. part
of the automated, adaptive benchmarking controls included a
sophisticated system and performance modeling implemented in APL
... which would evaluate configuration and workloads tested to date,
along with the resulting thruput and performance against thruput and
performance predicated by the models ... as part of specifying the
next workload/configuration combination to be test
https://www.garlic.com/~lynn/submain.html#benchmark
most of this was all done in a system infrastructure that was also
considered extremely secure ... the there were at least as many system
infrastructure issues related to security as there were related to
thruput and performance.
an old reference related to the infrastructure and security
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
some of the claims in this patent portfolio ... while primarily
oriented around authentication ... does stray into parameterised,
adaptable security operation within an overall, consistent security
infrastructure
https://www.garlic.com/~lynn/aadssummary.htm
for this 40+ plus year old technology ... which is seeing somewhat of
a resurgence ... both for addressing resource management as well as
for addressing security issues.
misc. recent posts mentioning resurgence of 40+ year old technology
https://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs
https://www.garlic.com/~lynn/2007b.html#11 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#21 history question
https://www.garlic.com/~lynn/2007b.html#23 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#26 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#28 What is "command reject" trying to tell me?
https://www.garlic.com/~lynn/2007e.html#20 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#63 FBA rant
https://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question
https://www.garlic.com/~lynn/2007h.html#2 The Mainframe in 10 Years
https://www.garlic.com/~lynn/2007h.html#23 MIPS and RISC
https://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007i.html#15 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007k.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#50 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#52 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#54 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#23 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#63 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#65 mainframe = superserver
https://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted
https://www.garlic.com/~lynn/2007n.html#27 What if phone company had developed Internet?
https://www.garlic.com/~lynn/2007o.html#1 Hypervisors May Replace Operating Systems As King Of The Data Center
https://www.garlic.com/~lynn/2007o.html#7 Hypervisors May Replace Operating Systems As King Of The Data Center
https://www.garlic.com/~lynn/2007o.html#9 Hypervisors May Replace Operating Systems As King Of The Data Center
https://www.garlic.com/~lynn/2007p.html#7 what does xp do when system is copying
https://www.garlic.com/~lynn/2007p.html#28 Newsweek article--baby boomers and computers
https://www.garlic.com/~lynn/2007q.html#3 Virtualization: Don't Ask, Don't Tell
Fingerprint Firefox Plugin?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fingerprint Firefox Plugin?
Date: Wed, 24 Oct 2007 14:57:32 -0400
To: cryptography@xxxxxxxx
zooko wrote:
Suppose you did have a convenient way to display the SSL certificate for
every site whenever you loaded a page from the site. You probably
wouldn't want to memorize all the certificates for the secure sites that
you care about, so you might instead write some notes on a piece of
paper next to your computer, for example writing down an SSL certificate
and then next to it writing "bank", and then writing down another one
and then next to it writing "mail", and so on.
Then, whenever you load a page, you would look at the SSL certificate
that is linked to that page and glance at your notepad to see which
description it maps to. If you are looking at a random web site that
you've never seen before, and the certificate doesn't appear on your
notes, then no big deal. If you are looking at a page that appears to
belong to your bank, and the certificate that came with that page
doesn't appear on your notes, then this is a big red flag! Likewise, if
you are looking at a page that appears to belong to your bank, and the
certificate appears on your notes, but the note next to it doesn't say
"bank", then this is a red flag, too! For example, it might be the
certificate of your mail service, which appears on your paper along with
the note "mail". Or it might just be a certificate that appears on your
paper along with the note "joke site from Harry".
Note that a system which classified certificates into "trusted" or
"untrusted" categories might give you the green flag even when a
certificate that you trust to serve up good jokes is serving up
something that appears to be your bank account.
So, the thing about writing down certificates and mapping them to short
hand-written notes is what the Pet Name Toolbar automates for you:
https://addons.mozilla.org/en-US/firefox/addon/957
the design point for certificates was first time communication between
total strangers (aka the letters of credit/introduction from sailing
ship days).
certificates have also somewhat tried moving into no-value market
segment for relying parties that had no (and/or couldn't cost justify)
mechanism for recording information about other parties they were
dealing with.
by comparison pgp had assumed some mechanism for relying parties being
able to record information about the parties that they had dealings
with. huge number of infrastructures have had well entrenched
infrastructures for recording information about parties that they
dealt with ... it just has been that the authentication related
information (for these infrastructures) have tended to be shared-secrets. many of these infrastructures could have been upgraded from
shared-secrets to public key ... w/o having any impact on the business
and/or trust models ... and furthermore by the very nature of the
existing infrastructures, the paradigm behind digital certificates
wasn't applicable (i.e. digital certificates being totally redundant
and superfluous).
recent thread/posting about it being much more natural for simple
upgrade of kerberos infrastructure from shared-secrets to public key
... w/o the exorbitant additional overhead and processing introduced
by digital certificates.
https://www.garlic.com/~lynn/2007q.html#2 Windows Live vs Kerberos
https://www.garlic.com/~lynn/2007q.html#5 Windows Live vs Kerberos
when we were called in to consult with this small client/server
startup that wanted to do payment transactions on their server
... since then somewhat has come to be called electronic commerce
https://www.garlic.com/~lynn/subnetwork.html#gateway
one of the technologies they had invented was SSL ... and we had to do
some work on applying SSL to real business processes and also do some
end-to-end audits of the whole series of operations ... including
these things that we calling themselves certification authorities
one of the things that undermined original assumptions applying SSL to
business processes was the whole "click" paradigm ... discussed in
more detail in this recent post
https://www.garlic.com/~lynn/2007q.html#30
and the assumptions about SSL as countermeasure and the related threat
models.
another aspect of SSL, certification authorities, digital certificates
was the whole issue behind what is met by certification process
... and what certifications were represented by digital certificates.
during the initial decade or so of electronic commerce something over
70 percent of the transactions were done by less than 100 websites
(activity is highly skewed) These websites were both well known and
also carried a lot of repeat business ... invalidating one of the
original/primary justifications for having digital certificates. so a
very few websites did majority of transactions and didn't need
certification. by comparison, the vast majority of websites were only
doing a very, very few electronic transactions (especially those
involving large percentage of first interaction between complete
strangers) ... and couldn't cost justify expensive certification
process
the other issue was that (all) merchants were already paying a fairly
hefty "interchange fee" that acted as a form of warranty/insurance to
cover their client/consumers (actually proportional to the value of
the operations). by comparison, the certification authorities were
providing almost no added value ... so except for pure hype ... there
was no real reason for spending money for additional certification (at
least from the standpoint of electronic commerce) ... which somewhat
gave rise to the thread about "merchant comfort certificates" in some
of the older ssl domain name certificate postings
https://www.garlic.com/~lynn/subpubkey.html#sslcert
a combination of these factors continued to push PKIs, certification
authorities, and digital certificates more and more into the no-value
market segment.
Oddly good news week: Google announces a Caps library for Javascript
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 11, 2007 11:03 AM
Subject: Oddly good news week: Google announces a Caps library for Javascript
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000984.html
some capability based trivia ... repeated here
https://www.garlic.com/~lynn/2007s.html#17
some earlier work on capability based infrastructure was the Gnosis
done starting in the 70s by Tymshare. Tymshare had a vm370-based
commercial, online timesharing system
https://www.garlic.com/~lynn/submain.html#timeshare
When Tymshare was bought by M/D, Gnosis was spun off as KeyKOS
(disclaimer, I was brought in to audit Gnosis as part of the spin-off)
Other trivia, M/D sold off Tymshare's TYMNET to B/T.
KeyKOS Documentation webpage
http://www.agorics.com/Library/keykosindex.html
other efforts that grew out of KeyKOS:
EROS: The Extremely Reliable Operating System
http://www.eros-os.org/
CapROS: The Capability-based Reliable Operating System
http://www.capros.org/
which has this reference back to KeyKOS
http://cap-lore.com/CapTheory/upenn/
The Coyotos Secure Operating System
http://www.coyotos.org/
from Coyotos history page ...
Coyotos is the successor to the EROS system, which is in turn the
successor to the KeyKOS system. Since the system inherits 30 years of
prior research and development history, it seems appropriate to
briefly describe some of that history and the prople who contributed
to it.
... snip ...
more from Coyotos history page ...
My own contact with this work came in 1990. As a co-founder of HaL
computer systems, I became involved in evaluating various operating
system platforms for use by HaL. In 1990, UNIX robustness wasn't
great, and we hoped to find something that would be largely operator
free and highly robust. Key Logic made a presentation to us about
KeyKOS. For reasons that were largely political, HaL decided not to
gamble on KeyKOS, but I became convinced that KeyKOS offered something
worthwhile.
... snip ...
for other trivia, the "H" in "HaL" had been head of the austin
workstation division (in an earlier life, for a time, I had been his
only direct report) and the "L" had come from SUN.
there use to be a joke in the valley that there were only 200 people
in the business ... they kept moving around, so it just appeared like
there were more.
How to crack RSA
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 19, 2007 06:46 PM
Subject: How to crack RSA
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000985.html
could claim that complexity of PC software & hardware was one of the
motivations behind EU finread terminal. One might also claim that this
is another instance of the sporadic reoccurring security refrain about
KISS
... and other recent refs:
Adding math to list of security threats (repeat from yesterday)
http://www.news.com/Adding-math-to-list-of-security-threats/2100-7349_3-6219153.html
Microprocessor math bugs pose security risk, warns cryptographer
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9047899
Cryptography Expert Sounds Alarm At Possible Math Hack
http://it.slashdot.org/article.pl?sid=07/11/19/0240210
MITM spotted in Tor
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 15, 2007 11:05 AM
Subject: MITM spotted in Tor
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000987.html
for topic drift ... i mention here
https://www.garlic.com/~lynn/2007u.html#74
in a thread about using on-screen visual keyboards (CAPTHAs obscured)
https://www.garlic.com/~lynn/2007u.html#66
and mouse clicks as countermeasure to PC virus/trojans capturing
online banking userid/passwords.
this is PC virus/trojan that waits until the session has been
initiated ... and then executes fraudulent transactions w/o the
person's knowledge
New Trojan Attacks Clients At Four Worldwide Banks
http://www.crn.com/security/204803106
Sophisticated Trojan loots business bank accounts
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9053018
Botnet-controlled Trojan robbing online bank customers
http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html
the original thread had drifted into topic that the
threats/vulnerabilities had been well-studied and understood by at
least the mid-90s ... along with the current spate of kneejerk,
simple-minded, point solutions for each individual exploit that
appears, rather than addressing underlying infrastructure weaknesses.
in the case of the online banking visual keyboard scenario ... it is
obviously a countermeasure to compromised PC ... then where does it
say that a compromised PC will only be limited to keylogging.
one could claim that the original SSL design (before the mid-90s) was
countermeasure to hostile environment ... not only did the session
have to be authenticated ... but everything related to the session had
to also be armored.
if the environment is really hostile, then it is much better going to
individual armored transaction instead of assuming that everything
within a session boundary is secure ... somewhat discussed in old
thread here last summer on naked transactions
https://www.garlic.com/~lynn/subintegrity.html#payments
comments about the culture of kneejerk simple-minded point-solution
reaction to exploits
https://www.garlic.com/~lynn/2007e.html#12 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#66 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#67 open source voting
https://www.garlic.com/~lynn/2007k.html#55 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series
https://www.garlic.com/~lynn/2007u.html#53 folklore indeed
https://www.garlic.com/~lynn/2007u.html#55 folklore indeed
https://www.garlic.com/~lynn/2007u.html#57 folklore indeed
https://www.garlic.com/~lynn/2007u.html#62 folklore indeed
https://www.garlic.com/~lynn/2007u.html#63 folklore indeed
https://www.garlic.com/~lynn/2007u.html#67 folklore indeed
https://www.garlic.com/~lynn/2007u.html#68 folklore indeed
2007: year in review
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 22, 2007 04:03 PM
Subject: 2007: year in review
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000988.html
my two bits on some of the subjects
part of the payment issue is whether it is a transaction business or a
risk management business.
if it is a transaction business ... then one might expect lots of
efforts to make it more efficient and less risky.
if it is a risk management business ... then it might be construed
that if all risk were to be eliminated ... there wouldn't be much to
manage anymore.
for more than a decade there has been predictions that telcos would
move in and take over the payment transaction business ... because
they are already extremely efficient at managing call record
transactions. there has been numerous claims that has yet to happen
because telcos haven't figured out how to do the risk management end
better.
some recent posts related to pdas/cellphones moving into payment transactions
https://www.garlic.com/~lynn/2007u.html#11 Public Computers
https://www.garlic.com/~lynn/2007u.html#47 folklore indeed
https://www.garlic.com/~lynn/2007v.html#37 Apple files patent for WGA-style anti-piracy tech
and for some cybercrime issues ... recent post
https://www.garlic.com/~lynn/2007v.html#35 Inside a Modern Malware Distribution System
The referenced modern malware articles make mention of the "new, 40+
yr old" technology ... however, my first exposure wasn't until the
last week of jan68 as an undergraduate (a few weeks short of
40yrs). However, over the next two years ... as an undergraduate at
the univ, I significantly redesigned and rewrote much of the original
kernel.
The malware article is also somewhat related to the virus/trojan
attacks on online banking systems ... which (with a little topic
drift) raised in this post:
https://www.garlic.com/~lynn/aadsm27.htm#65 MITM spotted in Tor
there have been several ongoing themes that the "new 40+ yr old"
technology will be the saving solution to all sorts of current
computing ills (and whether or not 2008 will be the year of virtual
machines).
AADS Postings and Posting Index,
- previous
- next
- home