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.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://www.garlic.com/~lynn/subpubkey.html#sslcert
i've mentioned before that we subsequently worked on x9.59 financial
transaction protocol
http://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 comingly now
called electronic commerce). recent post here
http://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
http://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):
http://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).
http://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
http://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
http://www.garlic.com/~lynn/lhwemail.html#crypto
including one from may81 about a proposal for online network service
for trusted public key distribution
http://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:
http://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
http://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
http://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 ...
http://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:
http://www.garlic.com/~lynn/2007f.html#72 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007g.html#8 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007g.html#55 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007i.html#40 Best practices for software delivery
http://www.garlic.com/~lynn/2007i.html#58 John W. Backus, 82, Fortran developer, dies
other posts mentioning MITM-attacks
http://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.
http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
and old standby post about security proportional to risk
http://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:
http://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
http://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:
http://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.
http://www.garlic.com/~lynn/subpubkey.html#signature
related and slightly facetious posting here:
http://www.garlic.com/~lynn/aadsm26.htm#69 survey of RFC S/MIME signature handling
as part of this thread
http://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)
http://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:
http://www.garlic.com/~lynn/2007j.html#67 open source voting
http://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:
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#5 Leadership, the very definition of fraud, and the court of security ideas
http://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.
http://www.garlic.com/~lynn/2007j.html#67 open source voting
this somewhat tempts to stray into the subject nothing succeeds like
failure ... referenced here:
http://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)
http://www.garlic.com/~lynn/2005t.html#25 Why does my address appear as part of my name?
http://www.garlic.com/~lynn/2007e.html#12 Securing financial transactions a high priority for 2007
http://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
http://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
http://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
http://www.garlic.com/~lynn/subintegrity.html#payments
from a slightly different perspective
http://www.garlic.com/~lynn/2007k.html#12
http://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:
http://www.garlic.com/~lynn/2007k.html#48
somewhat older reference:
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm
Is this Risk Management's Waterloo?
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 20, 2007 11:27 AM
Subject: Is this Risk Management's Waterloo?
Blog: Financial Cryptography
re:
http://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
http://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
http://www.garlic.com/~lynn/index.html#glosnote
I've drawn on numerous sources for merged security taxonomy and glossary
http://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:
http://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
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and collection of posts mentioning payment processing and payment
gateway
http://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
http://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
http://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
http://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
http://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardized Security Protocols are Too Heavy
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://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)
http://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)
http://www.garlic.com/~lynn/2006w.html#email810515
in this post
http://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)
http://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)
http://www.garlic.com/~lynn/2006w.html#email810515
in this post
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
re:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
and rfc editor announcement from today .... my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
http://www.garlic.com/~lynn/rfcidx16.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)
http://www.garlic.com/~lynn/rfcidx16.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
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://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
http://www.garlic.com/~lynn/2007k.html#33
and old email (also predating DNS) proposing online, real-time public
key serving
http://www.garlic.com/~lynn/2006w.html#email810515
in this post
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
somewhat topic drift with DNS related trivia ... more than a decade before
DNS
http://www.garlic.com/~lynn/2007k.html#33
and some old email (predating dns) suggesting online, realtime public key
server
http://www.garlic.com/~lynn/2006w.html#email810515
in this post
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://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
http://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.
http://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"
http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection against DOS
http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec
http://www.garlic.com/~lynn/2007d.html#37 MAC and SSL
http://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits?
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://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
http://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
http://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 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
http://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
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
http://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)
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies
http://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
http://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):
http://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
http://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)
http://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
http://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
http://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)
http://www.garlic.com/~lynn/subtopic.html#sgml
was invented at the science center in 1969
http://www.garlic.com/~lynn/subtopic.html#545tech
... some recent (science center) topic drift/references in this post
http://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)
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:
http://www.slac.stanford.edu/history/earlyweb/history.shtml
recent historical post/reference
http://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)
http://www.garlic.com/~lynn/subtopic.html#timeshare
lots of past posts about long term performance monitoring, workload profiling,
benchmarking and stuff leading up to things like capacity planning
http://www.garlic.com/~lynn/subtopic.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
http://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.
http://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 useable 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:
http://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
http://www.garlic.com/~lynn/subtopic.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:
http://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
http://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
http://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives
http://www.garlic.com/~lynn/2007l.html#68 nouns and adjectives
http://www.garlic.com/~lynn/2007l.html#69 nouns and adjectives
http://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:
http://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
http://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
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
http://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?
http://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
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:
http://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.
http://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.
http://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:
http://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.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://www.garlic.com/~lynn/subpubkey.html#catch22
other posts about certificate-less public key operation
http://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
http://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
http://www.garlic.com/~lynn/x959.html#x959
that are armored with digital signature (integrity and authentication)
... misc. posts mentioning "naked" transaction metaphor
http://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.
http://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
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
slight addendas ...
1) EU finread
http://www.garlic.com/~lynn/subintegrity.html#finread
http://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)
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://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).
http://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:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://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/