Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- maximize best case, worst case, or average case? (TCPA)
- 3D Secure GUI
- 3D Secure GUI
- 3D-Secure and Passport
- 3D-Secure and Passport
- 3D-Secure and Passport
- 3D-Secure and Passport
- 3D-Secure and Passport
- 3D Secure and EMV
- Crypto Forum Research Group ... fyi
- 3D Secure and EMV
- Some security, fraud, attack, threat, references
- TOC for world bank e-security paper
- anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
- Challenge to TCPA/Palladium detractors
- Challenge to TCPA/Palladium detractors
- Feasability of Palladium / TCPA
- Overcoming the potential downside of TCPA
- Overcoming the potential downside of TCPA
- TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
- draft-ietf-pkix-warranty-ext-01
- Smartcard in CD
- draft-ietf-pkix-warranty-ext-01
- 10 choices that were critical to the Net's success
- Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
- Cryptogram: Palladium Only for DRM
- I-D ACTION:draft-ietf-pkix-usergroup-01.txt
- Employee Certificates - Security Issues
- Employee Certificates - Security Issues
- Employee Certificates - Security Issues
- Employee Certificates - Security Issues
- The Bank-model Was: Employee Certificates - Security Issues
- Employee Certificates - Security Issues
- two questions about spki
- Banks + Legally binding signatures = A mess
- Electronic Security: Risk Mitigation in Financial Transactions
- two other financial electronic security related URLs
- Legal entities who sign
- Legal entities who sign
- Identification = Payment Transaction?
- In Brief: Anti-'Skimming' Guidelines Coming
- I-D ACTION:draft-ietf-pkix-sim-00.txt
- draft-ietf-pkix-warranty-extn-01.txt
- draft-ietf-pkix-warranty-extn-01.txt
- Identity Theft More Often an Inside Job
- draft-ietf-pkix-warranty-extn-01.txt
- Fraudit helps registrars battle global online fraud
- Online Fraud Growing in Scale, Sophistication
- draft-ietf-pkix-warranty-extn-01.txt
- draft-ietf-pkix-warranty-extn-01.txt
- Frist Data Unit Says It's Untangling Authentication
- Frist Data Unit Says It's Untangling Authentication
- First Data Unit Says It's Untangling Authentication
- TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
- TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
- TTPs & AADS (part II)
- TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
- eBay Customers Targetted by Credit Card Scam
- Time to ID Identity-Theft Solutions
- e-Government uses "Authority-stamp-signatures"
- signing & authentication (was Credit Card Scam)
- Intertrust, Can Victor Shear Bring Down Microsoft?
- Intertrust, Can Victor Shear Bring Down Microsoft?
- Intertrust, Can Victor Shear Bring Down Microsoft?
- Invisible Ink, E-signatures slow to broadly catch on (addenda)
- Online shopping passes $11 billion
- Subpoena Sidelines PKI Project
- Offline Root CA with valid CRL hierachie
maximize best case, worst case, or average case? (TCPA)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/30/2002 01:49 PM
To: Ryan Lackey <ryan@xxxxxxxx>
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
Digital Bearer Settlement List <dbs@xxxxxxxx>,
dcsb@xxxxxxxx, "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: maximize best case, worst case, or average case? (TCPA)
"security modules" are also inside the swipe & pin-entry boxes that you see
at check-out counters.
effectively both smartcards and dongles are forms of hardware tokens ....
the issue would be whether a smartcard form factor might be utilized in a
copy protection scheme similar to TCPA paradigm .... a single hardware chip
that you register for all you applications .... or in the dongle paradigm
.... you get a different smartcard for each application (with the downside
of the floppy copy protection scenario where a user with a half dozen
active copy protected applications all wanted "their" smartcard crammed
into the same smartcard reader simultaneously).
many of the current chipcards .... i believe are used in the magnetic
stripe "swipe" mode for authenticating specific transactions .... most of
the rest are used for password substitute at login type events. Many of the
chipcards following the straight payment card model result in end-user
having large number of different institutional tokens (similar to the
floppy copy protect paradigm). Following the institutional-specific and/or
application-specific token paradigm starts to become difficult to manage as
the number of tokens increase and the probability that multiple are
required simultaneously increases.
That eventually leads into some sort of person-centric or device-centric
paradigm .... not so much an issue of the form factor (floppy, chipcard,
dongle, etc) .... but an issue of whether there are potentially large
numbers of institutional/application specific objects or small numbers of
person/device specific objects.
So a simple issue is the trade-off between the institutional/application
specific objects .... which seem to have some amount of acceptance (payment
cards, chip cards, various "dongle" forms, etc) but in many instances can
scale poorly ... especially if multiple different such objects have to be
available concurrently .... vis-a-vis switching to a person/device specific
object paradigm (chipcard, dongles, etc, potentially exactly same
formfactor but different paradigm)
ryan@xxxxxxxx on 6/30/2002 12:39 pm wrote:
I think dongles (and non-copyable floppies) have been around since the
early 80s at least...maybe the 70s. Tamper-resistant CPU modules have
been around since the ATM network, I believe, in the form of PIN
processors stored inside safes)
The fundamental difference between a "dongle" and a full "trusted
module" containing the critical application code is that with a
dongle, you can just patch the application to skip over the checks
(although they can be repeated, and relatively arcane).
If the whole application, or at least the non-cloneable parts of the
application, exist in a sealed module, the rest of the application can't
be patched to just skip over this code.
Another option for this is a client server or oracle model where the
really sensitive pieces (say, a magic algorithm for finding oil from
GIS data, or a good natural language processor) are stored on
vendor-controlled hardware centrally located, with only the UI
executing on the end user's machine.
What I'd really like is a design which accomplishes the "good" parts
of TCPA, ensuring that when code claims to be executing in a certain
form, it really is, and providing a way to guarantee this remotely --
without making it easy to implement restrictions on content copying.
It would be nice to have the good parts of TCPA, and given the
resistance to DRM, if security and TCPA have their fates bound,
they'll probably both die an extended and painful death.
I suppose the real difference between a crypto-specific module and a
general purpose module is how much of the UI is within the trusted
platform envelope. If the module is only used for handling
cryptographic keys, as an addition to an insecure general purpose CPU,
with no user I/O, it seems unlikely to be useful for DRM. If the
entire machine is inside the envelope, it seems obviously useful for
DRM, and DRM would likely be the dominant application. If only a
limited user IO is included in the envelope, sufficient for user
authentication and keying, and to allow the user to load
initially-trusted code onto the general purpose CPU, but where the
user can fully use whatever general purpose code on the general
purpose CPU, even uncertified code, with the certified module, it's
not really useful for DRM, but still useful for the non-DRM security
applications which are the alleged purpose behind TCPA.
(given that text piracy doesn't seem to be a serious commercial
concern, simply keeping video and audio playback and network
communications outside the TCPA envelope entirely is good enough, in
practice...this way, both authentication and keying can be done in
text mode, and document distribution control, privacy of records,
etc. can be accomplished, provided there is ALSO the ability to do
arbitrary text processing and computing outside the trusted envelope,
.)
If it's the user's own data being protected, you don't need to worry
about the user intentionally circumventing the protections. Any
design which removes control from the 'superuser' of the machine is
fundamentally about protecting someone other than the user.
This, I think, is the difference between TCPA and smartcards. Notice
which one has in its short lifetime attracted far more enmity :)
--
Ryan Lackey [RL7618 RL5931-RIPE] ryan@xxxxxxxx
CTO and Co-founder, HavenCo Ltd. +44 7970 633 277
the free world just milliseconds away http://www.havenco.com/
OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F
3D Secure GUI
From: Lynn Wheeler
Date: 07/08/2002 08:37 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: amolnatu@xxxxxxxx.ae,
internet-payments <internet-payments@xxxxxxxx>,
epay@xxxxxxxx
Subject: Re: 3D Secure GUI
Nacha also had an aads pilot with digital signature (both with software &
chipcards) .... see 7/23/2001 "secure ATM card"
http://internetcouncil.nacha.org/News/news.html
it was close to the x9.59 standard mapping to iso8583 standard
http://www.garlic.com/~lynn/x959.html#x959
anders.rundgren@xxxxxxxx on 7/7/2002 11:39 pm wrote:
Amol,
Interesting this NACHA project. It seems like a direct copy
of what banks are doing in many places in the world. Many quite ahead
of 3D Secure in my opinion, but also totally disparate technically.
This also shows that when banks create their own preferred solution, it
is centered around the bank rather than around a card.
Now regarding your concerns I have some problems understanding
what the problem is:
>1. The status of the transaction completion is not available to the merchant
>as the transactions gets completed totally within the bank.
In all these schemes the merchant must of course get either a
"receipt" or an authenticated payment authorization (like in 3D)
depending on the type of payment. The way the this message reaches the
merchant varies from 3D's (in my opinion pretty inferior) server-
browser-server solution, to schemes using reliable messaging.
>2. It is cumbersome for the merchant to link the purchase details with the
>actual payment transaction.
You mean because it is not taking place within a Web-session?
In many of these schemes it works as in 3D as it is just a change
in GUI (as the subject line imply), but in some other schemes the
merchant needs to store the message somewhere during checkout
as well.
>3. It involves a large change to the existing card processing systems i.e
>the acquiring systems, card scheme would have no knowledge of authorisation
>prior to actual settlements.
I don't think this is the case, as the flow of information is not changed,
just formats.
Cheers,
Anders
3D Secure GUI
From: Lynn Wheeler
Date: 07/08/2002 09:22 AM
To: ANSHU NAHAR /NIG/CRP <anshu.nahar@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, 'Anders Rundgren' <anders.rundgren@xxxxxxxx>,
internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: RE: 3D Secure GUI
note that in the previous reference to X9.59, X9.59 was designed to be
a payment method agnostic standard .... applicable to all payments in
all environments (at least both debit & credit).
The NACHA pilot demonstrated a AADS (some of the data elements were
differed from that in the X9.59 standard) to ISO8583 mapping for
debit. However, a similar mapping is showed for ISO8583 for credit.
The X9.59 (and NACHA) mapping to ISO8583 uses the same exact flow as
currently is implemented .... aka there is no change in the existing
message flows for either credit or debit .... and all the business
processes remain identical. The standard to ISO8583 mapping just adds
a few more data elements to the existing message standards w/o
changing the message flow or processing.
anshu.nahar@xxxxxxxx on 7/4/2002 11:49 pm wrote:
"...Then the payment is carried out in the bank-environment..."
This is exactly the approach we have been using at our Bank for more than 3 years.
1. The customer "checks out" from the web merchant's site.
2. He is directed to ICICI Bank's site.
3. The payment is completed under "Bank's environment".
4. The customer is directed back to web merchant after payment processing.
The difference is that is approach is used to effect direct account debit rather than for credit cards.
Regards
Anshu Nahar
[3d-secure] NEWS: 3D-Secure and Passport
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/09/2002 08:14 PM
To: donpark@xxxxxxxx, internet-payments@xxxxxxxx, epay@xxxxxxxx
cc: "'MacDougall, Alan'" <Alan.MacDougall@xxxxxxxx>
Subject: RE: [3d-secure] NEWS: 3D-Secure and Passport
Note that the host of the internet-payments mailing list has had a
FAST project ... aka a consumer sign something authorizing a 3rd party
to ask their financial institution a question ... and the financial
institution can answer yes/no (or ???) ... much the same way the
answer yes/no to debit & credit requests in iso8583.
note that financial institutions already answer questions about their
customers ... aka you give a bank as a reference for a number of
different things & circumstances .... which the bank then
corroborates. That is different than a bank issuing a general identify
certificates.
I've made a number of recent postings about financial institutions
being able to migrate existing business processes to an electronic,
digitial signed environment (w/o resorting to a certificate) like as
described in the FAST project. it doesn't have to be a PKI ... it can
be a little pki. a past discussion on some of these issues
(furthermore, it isn't new business operations ... it is applying some
additional technology to existing business operations, you might even
be able to utilize the existing iso8583 financial networks to carry
some of the messages):
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsmore.htm#x959demo AADS & X9.59 demos at BAI (annual world-wide retail banking) show in miami next week
http://www.garlic.com/~lynn/aepay6.htm#userauth MS masters NC mind-set (authentication is the key)
http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
http://www.garlic.com/~lynn/ansiepay.htm#x959demo X9.59/AADS demos operational
http://www.garlic.com/~lynn/99.html#216 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
donpark@xxxxxxxx at 7/9/2002 7:52 pm wrote:
Alan,
> This will work assuming that a Bank would be happy
> outsourcing authentication services to a third party (let
> alone that third party being Microsoft).
True. At this point, it's the business issues that banks will have to
consider. As one can see from a brief visit to Slashdot, there is no
shortage of misinformed paranoid people in the world. Technically, its
as secure as basic 3D-Secure authentication. There was an issue over
security of Passport inline UI, but that feature was deprecated recently
and 3D-Secure Passport integration no longer uses it.
> Personally I see Banks potentially as a source of
> authenticated users for other organisations (ie, other
> organisations trust the Banks to authenticate mutual users)
> rather than a recipient of users of other organisations'
> authentication processes (ie, the Banks trust
> Microsoft/Liberty Alliance to authenticate mutual users).
I understand where you are coming from. Using banks as PKI foundation
is an old idea that is still valid. There are two problem with the
idea:
1. Most banks and issuers are not equipped to provide general
authentication service.
2. It doesn't fit their business model.
3. Authentication service as a business is yet to be proven.
Integration of Passport with 3D-Secure uses a variation of that idea,
using ONE-WAY binding link from one or more 3D-Secure accounts to a
Passport account. Each of these links are created whenever a user
enrolls into 3D-Secure program and selects Passport as his/her
authentication method. Because each of these links represents a form of
trust, the Passport account takes on more substance than mere e-mail
address.
Allow me to point out a copule of facts in an attempt to dispell some
myth about Passport integration with 3D-Secure:
First, credit card information NEED NOT BE stored in Passport accounts.
You may do so, but I don't recommend it.
Second, due to one-way nature of the links, there is minimal impact from
Passport accounts being compromised and link can be broken once fraud is
detected.
Best,
Don Park
Docuvers
NEWS: 3D-Secure and Passport
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/14/2002 10:01 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, donpark@xxxxxxxx,
'Internet-Payments' <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: NEWS: 3D-Secure and Passport
Part of the issue of SSO is can it be used to impersonate you in
different security domains. One of the reasons for the requirement for
different (shared-secret) passwords in different security domains
.... is that the "authorities" in one security domain might otherwise
be able to impersonate you in other security domains. The other issue
related to SSO ... is ever product requiring some sor tof access
authentication implementing their own (shared-secret) password
mechanism.
One SSO mechanism might be once you connect to your ISP and
(predominately RADIUS) authenticates you to the ISP ... having the ISP
supply authentication information to every subsequent web-related
access that you make requiring authentication. The downside is that
you may be using a garage operation ISP run by a couple young techno
wizards and you do internet banking (even if they aren't interested in
performing fraud the physical security of their operation may not mean
that anybody else can't enter their facility and perform fraud).
Security,. integrity, etc in different security domains may be
signfiicantly different levels (20 plus years ago looking at allowing
corporate travelers to access email from hotels, many hotel PBXs were
identifiied has having a variety of significant security
vulnerabilities, requiring special modem cards implementing
challenge/response, key exchange, session encryption, etc, sort of an
SSL of the late '70s). The whole area of open, unsecured (inter)
networks has significantly compounded the vulnerabilities.
So an issue of internet/intranet SSO .... relates to shared-secret
passwords and cross domain security & authentication. That also has
been an issue of using trusted 3rd parties as part of an
authentication infrastructure (in the crypto mailing list there is a
recent thread on the extremely wide variation in integrity levels of
some of the different SSL certificate vendors ... and the way SSL
certificates currently operation mean that the trust level is
effectively the lowest common denominator).
Back in the late '80s doing technical audits of Project Athena ... sat
thru an all day session on the original definition of cross-domain
authentication in Kerberos ... it wasn't so much a technology issue
.... it was a business issue; things like who took the liability. If
there was cross-domain Kerberos authentication between two
corporations ... did one corporation accept full liability for any
actions by entities that had been cross-domain authenticated (whether
the entitties were actual employees of that corporation or somebody
impersonating an employee of that corporation).
Note that authentication doesn't have to equate to identity. In
theory, it is possible to register for a new account with an ISP
... and have a userid and a password. The password just authenticates
that you are the person authorized to use the account. As long as the
ISP gets paid .... in principle that need not know who you are. An
ISP-based SSO would have the ISP supplying your authenticated userid
to every subsequent web location you connect to (identity is not
stamped on every ISP operation, but lets say your ISP persona is
stamped on everything). Now, some governments around the world might
want a "know your customer" rule ... for ISPs similar to similar fules
in the financial industry.
cryptography archive ... thread is: SSL Certificate Monopoly Bears
Financial Fruit:
http://www.mail-archive.com/cryptography%40wasabisystems.com/maillist.html
other related discussions to how SSL domain name certificates operate:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
some past postings on identity, authentication and privacy
http://www.garlic.com/~lynn/subtopic.html#privacy
one of the original SSOs is kerberos, kerberos is a IETF/internet standard.
for kerberos related RFCs go to
http://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#)
and scroll down to Kerberos
kerberos
see also authentication , security
3244 3129 2942 2712 2623 1964 1510 1411
description of kerberos working group:
http://www.ietf.org/html.charters/krb-wg-charter.html
at the above there is a draft for a kerberos network authentication
service (drafts/versions only have a six month life time, sometimes
one draft will die, be removed, and there will be a lapse until an
updated version is reborn).
the dominant internet-related authentication mechanism is radius (also an
internet stnadard) used by ISPs. RADIUS related RFCs can be found in the
indexed referenced above:
remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138
2059 2058
also, radius related items:
http://www.garlic.com/~lynn/subtopic.html#radius
anders.rundgren@xxxxxxxx on 7/14/2002 2:31 am wrote:
Don,
OK. Being a part-designer of such I tend to disagree:
http://web.archive.org/web/20021012183030/shibboleth.internet2.edu/SHIB-05-Sept-2001.html
>I believe authentication should
>require a concious and visible user action.
Me too. But SSO on the Internet (in contrast to an Intranet) does not
necessarily mean that you just login once, but rather that you can use
the same method and data at many different places.
> SSO tatoos my identity on my forehead just so I don't have to
>reach for my wallet. Yikes.
Is this a privacy concern or what?
NEWS: 3D-Secure and Passport
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/14/2002 01:14 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, donpark@xxxxxxxx,
epay@xxxxxxxx, 'Internet-Payments' <internet-payments@xxxxxxxx>
Subject: Re: NEWS: 3D-Secure and Passport
There are at least 2-3 kinds of SSOs ...
1) the ones that you give it all your current passwords .... and you
authenticate yourself to the SSO which then spoofs a login using the
appropriate password into some other environment ... the "owners" of
that SSO then have all your passwords ... potentially across mutliple
security domains and could effect a non-SSO direct login impersonating
you (this is somewhat related to non-repudiation).
2) the kerberos kind of ticket SSOs ... where you authenticate
yourself to kerberos servers and it provides tickets that can be used
with other services. the identity of the original kerberos agency is
involved here ... since the other services need to know which
kerberos service they might be trusted (see previous references to
kereros which goes back possibly 15 years). Note that kerberos is the
standard in w2000 and beyond (the pre-amble in the referenced kerberos
"draft" from previous note touches on some of this). Cross-domain
kerberos authentication has been a long term issue ... not so much
because of technology issues .... but business and liability issues/
http://www.garlic.com/~lynn/aadsm12.htm#4 3d-secure and passports
3) (sort-of) SSL server certificates and trusted 3rd parties (aka you
accept the athentication for session setup based on the information in
the certificate). note as mentioned many times previously ... a
primary purpose for SSL server certificates is because of integrity
issues with the domain name infrastructure .... however TTPs issuing
SSL server certificates are also dependent on the integrity of the
domain name infrastructure; any improvement in the integrity of the
domain name infrastructure for purposes of the TTPs issuing SSL server
certificates .... contributes to reducing the justification for having
SSL server certificates (i.e. integrity/trust issues in the domain
name infrastructure). In effect, significant improvement in the trust
for SSL server certificates also contributes to not needing them. This
sort of complicates any sort of long term business plan (for example
if SSL server certificates ever become sufficiently onerous ... it
would might also justify fixing the domain name infrastructure
... eliminating SSL server certificates):
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
anders.rundgren@xxxxxxxx on 7/14/2002 11:27 am wrote:
Lynn,
>Part of the issue of SSO is can it be used to impersonate you in different
>security domains. One of the reasons for the requirement for different
>(shared-secret) passwords in different security domains .... is that the
>"authorities" in one security domain might otherwise be able to impersonate
>you in other security domains.
This is solved in SAML/Liberty/OBI Express etc. by marking the
signed SSO "ticket" with a target site which eliminates impersonation.
>The other issue related to SSO ... is ever product requiring some sor
>tof access authentication implementing their own (shared-secret) password
>mechanism.
If you have a central SSO-handler taking care of multiple sites/apps
you may indeed need such a mechanism. But even this part can easily
be performed by asymmetric crypto to get away from shared-secrets.
>That also has been an
>issue of using trusted 3rd parties as part of an authentication
>infrastructure (in the crypto mailing list there is a recent thread on the
>extremely wide variation in integrity levels of some of the different SSL
>certificate vendors ... and the way SSL certificates currently operation
>mean that the trust level is effectively the lowest common denominator).
Agreed. That's why it is surprising the financial industry cannot get
their act together and establish a trustworthy organization-level CA.
But probably the fraud-level for SSL-certs is still too low to justify
anything else.
Anders
NEWS: 3D-Secure and Passport
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/14/2002 01:57 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, donpark@xxxxxxxx,
epay@xxxxxxxx, 'Internet-Payments' <internet-payments@xxxxxxxx>
Subject: Re: NEWS: 3D-Secure and Passport
... oh yes, the issue wasn't reply type of attack for impersonation
.... the issue was leakage of valid authentication information thru
some accidental or purposeful fault in the SSO infrastructure.
lots of authentication protocols have reply resistance ... say in the
case of a digital signature orientation for RADIUS .... the server
transmits a time or other unique/random value. The user returns a
message with the servers time/unique-value, userid ... signed with
their digital signature.
Say a traditional RADIUS implementation transmits "enter userid" (this
can be in the clear as if it appears on a terminal .... or
encapsulated in a PPP message; .... I've seen ISPs do their front-end
radius with routing by sending down "enter userid" .... if it comes
back with straight userid ... then it is assumbed to be something
like telnet .... if it comes back with some prefix and some separation
character preceding the userid .... then it may be assumbed to be PPP
and the person is logging in to PPP ... then there are the ISPs that
only allow PPP).
In any case ... they might send down "7/14/02 13:00:00.xx enter
userid" ... in which case that whole character string is included in
a signed reply.
One issue has to do with whether you have a "chatter" authentication
protocol .... taking one or more exchanges of messages (where both
parties could contributed to the contents as a replay prevention
measure) ... or a "transaction" authentication protocol ... here
everything is piggy-backed in a single message (aka like in x9.59
where only one party gets to contribute information for replay
resistant purposes).
Also, note the original wasn't whether the relying party couldn't tell
whether it was an SSO or a direct authentication operation .... the
issue was whether any leakage of (authentication) information from an
SSO feature could result in a relying party authorizing a fraudulent
operation.(regardless of whether the audit trail subsequently showed
whether not things originated from SSO or not).
I'm not sure which you were referring to as being "solved" .... some
replay attack remediation by having a ticker marked for a specific
target site (relying party) ... minimizing using previously issued
tickets in some sort of replay (with the same or different relying
party, also various forms of insider attacks also involve use of
priviledged information for fraudulent transactions on the same site).
anders.rundgren@xxxxxxxx on 7/14/2002 11:27 am wrote:
This is solved in SAML/Liberty/OBI Express etc. by marking the
signed SSO "ticket" with a target site which eliminates impersonation.
NEWS: 3D-Secure and Passport
Refed: **, - **, - **
From: Lynn Wheeler
Date: 07/14/2002 02:25 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, donpark@xxxxxxxx,
epay@xxxxxxxx, 'Internet-Payments' <internet-payments@xxxxxxxx>
Subject: Re: NEWS: 3D-Secure and Passport
oh yes, from
http://www.garlic.com/~lynn/secure.htm
single sign-on
(I) A system that enables a user to access multiple computer platforms
(usually a set of hosts on the same network) or application systems after
being authenticated just one time. (C) Typically, a user logs in just once,
and then is transparently granted access to a variety of permitted
resources with no further login being required until after the user logs
out. Such a system has the advantages of being user friendly and enabling
authentication to be managed consistently across an entire enterprise, and
has the disadvantage of requiring all hosts and applications to trust the
same authentication mechanism. [RFC2828] (see also secure single sign-on,
authentication)
[3d-secure] 3D Secure and EMV
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/28/2002 08:05 AM
To: amolnatu@xxxxxxxx.ae
cc: 3d-secure@xxxxxxxx, <internet-payments@xxxxxxxx>,
epay@xxxxxxxx
Subject: RE: [3d-secure] 3D Secure and EMV
payment cards can include credit, debit, any sort of payment.
credit was initially used on the internet .... in part because of
relatively close fit with existing non-face-to-face business model
(MOTO, aka mail-order/telephone-order) support; i.e. AVS,
card-not-present, cardholder-not-present previsions:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2 assurance, e-commerce, and some x9.59
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 assurance, e-commerce, and some x9.59
debit was an issue since it didn't have a non-card-present model and
it depended on shared-secret authentication implemented in a private,
secure network with private, secure point-of-entry devices
(implementing trusted security modules).
NACHA has done an internet trial for ACH/debit ... using an AADS
model with public/private key cryptography using both software and
hardware tokens.
http://www.garlic.com/~lynn/x959.html#aads
http://internetcouncil.nacha.org/News/news.html
an issue is given appropriate technology then the trust level of
existing debit on private network with trusted security modules
.... can be approached or exceeded for public, non-trusted networks.
the PC industry has somewhat moved in a couple of direction
.... hardware tokens in chipcard form factor requiring ubiquitous card
reader deployment .... but also hardware tokens in USB dongle form
factor requiring ubiquitous USB port availability (there are also
combos that look like a 7816 chipcard on one end and USB dongle on the
other end).
For overlapping environments .... there is also some migration to iso
14443 proximity/contactless, especially for high-traffic areas.
One could imagine three or four different tokens all mapped to same
financial accounts ... a magstripe form factor, a 7816 form factor, a
14443 form factor and a USB dongle form factor ... or possible some
combo hardware tokens supporting multiple form factor operation
(magstripe, 7816, 14443, USB dongle, etc).
amolnatu@xxxxxxxx.ae on 7/28/2002 1:28 am wrote:
Hi
Probably this topic posed by Anders got missed out ... I would like
to understand the path that internet payments would take once EMV
cards are rolled out.
To my knowledge, banks implementing smart cards see no effect on
internet payments at this point in time i.e these payments will
continue to be non-authenticated and move to 3D secure in due course.
Once there is a large mass of smart card holders, would banks go ahead
with equipping them with readers ? How would this affect 3D ? Which
authentication would prevail ?
Any thoughts ...
Is the PC industry moving towards having smart card readers as default
hardware ...
Cheers
Amol
P.S. can someone send me links to popular EMV related mailing lists ?
Crypto Forum Research Group ... fyi
From: Lynn Wheeler
Date: 07/28/2002 07:42 AM
To: cryptography@xxxxxxxx
cc: epay@xxxxxxxx
Subject: Crypto Forum Research Group ... fyi
To IETF-Announce ;
Subject Crypto Forum Research Group
From Vern Paxson <vern@xxxxxxxx>
Date Fri, 26 Jul 2002 163850 -0400
A new IRTF research group, CFRG (Crypto Forum Research Group), has begun,
with the appended charter. Use cfrg-request@xxxxxxxx to subscribe to the
mailing list. See http://www.irtf.org/cfrg/ for further information.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Crypto Forum Research Group (CFRG) is a general forum for discussing and
reviewing uses of cryptographic mechanisms, both for network security in
general and for the IETF in particular.
CFRG serves as a bridge between theory and practice, bringing new
cryptographic techniques to the Internet community and promoting an
understanding of the use and applicability of these mechanisms via
Informational RFCs (in the tradition of, e.g., RFCs 1321 (MD5) and 2104
(HMAC)). Our goal is to provide a forum for discussing and analyzing general
cryptographic aspects of security protocols, and to offer guidance on the use
of emerging mechanisms and new uses of existing mechanisms. IETF working
groups developing protocols that include cryptographic elements are welcome
to bring questions concerning the protocols to CFRG for advice.
[3d-secure] 3D Secure and EMV
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: Sun, 28 Jul 2002 09:58:26 -0600
To: amolnatu@xxxxxxxx.ae
Cc: 3d-secure@xxxxxxxx,
"'Internet-Payments'" <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: RE: [3d-secure] 3D Secure and EMV
also slightly related discussion on form factor & ubiquitous deployment
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
somewhat related was a recent news on being able to use cellphones in
japan to operate an ATM machine.
cards have been a form of something you have authentication.
technology and wireless operation can "prove" you have something ....
without anybody actually seeing what it is you have .... aka a
wireless PDA or cellphone can contain a specific chip that contains a
unique value ... where the operation of the chip can "prove" that you
posses the chip. Furthermore, the chip can be designed to only
operate when presented with a valid PIN.
This would be combination of something you have and something you
know authentication. The technology difference compared to existing
PIN-debit ... where information on a magstripe and your PIN is
essentially transmitted over a closed, private, secure network .... is
that the technology used can imply just by its correct operation both
something you have and something you know w/o having to divulge or
show either.
This is the X9.59 and NACHA AADS digital signature operation .... a
chip signing an operation can imply two-factor authentication ... even
if the chip is embedded in a cellphone or PDA for wireless operation
and nobody actually physically observes it.
Some security, fraud, attack, threat, references
From: Lynn Wheeler
Date: 07/28/2002 01:56 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Some security, fraud, attack, threat, references
Internet Security Alliance:
A Trusted and Reliable Public-Private Partnership for Information
Sharing and E-security Issues
http://www.isalliance.org/
some resources:
http://web.archive.org/web/20041125092246/http://www.isalliance.org/resources/
technology briefs from above
Secure Infrastructure Design, This document was provided to ISAlliance
members in May. July 1, 2002
A Brief Tour of the Simple Network Management Protocol, This document
was provided to ISAlliance members in April. June 10, 2002
Organized Crime and Cyber-Crime: Implications for Business, This
document was provided to ISAlliance members in February. April 8,
2002
Downstream Liability for Attack Relay and Amplification, This paper was
based on a joint presentation at the RSA Conference 2002. March 15,
2002
Home Network Security, This document was provided to ISAlliance members
in October. March 4, 2002
Overview of Attack Trends, This document was provided to ISAlliance
members in January. February 19, 2002
Using PGP to Verify Digital Signatures, This document was provided to
ISAlliance members in December. January 28, 2002
Cross-Site Scripting Vulnerabilities, This document was provided to
ISAlliance members in November. January 15, 2002
Dealing with External Computer Security Incidents, This document was
presented to ISAlliance members in November. December 17, 2001
Managing the Threat of Denial-of-Service Attacks, ISA releases their
first Technology Brief. This document was presented to ISAlliance
members in October. November 15, 2001
External Resources:
Electronic Security: Risk Mitigation in Financial Transactions, World
Bank Financial Sector Report: June 2002 June 13, 2002
Mobile Risk Management: E-Finance in the Wireless Environment, World
Bank Financial Sector Discussion Paper: May 2002 May 28, 2002
TOC for world bank e-security paper
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Date: Sun, 28 Jul 2002 14:30:43 -0600
Subject: TOC for world bank e-security paper
with respect to world bank e-security paper:
http://web.archive.org/web/*/http://www.isalliance.org/resources/papers/E-security.pdf
the following is the table of contents
Abstract
Acknowledgments
Executive Summary
I. Introduction
II. What Is Electronic Security and Why Is It Needed?
III. The Electronic Security Industry
IV. Electronic Security Infrastructure within a Risk Management Framework
V. Pillar I: Legal Framework and Enforcement
VI. Pillar II. Electronic Security of Payment Systems
VII. Pillar III: Supervision and Prevention Challenges
VIII. Pillar IV: The Role of Private Insurance as a Complementary Monitoring Mechanism
IX. Pillar V: Certification, Standards, and the Role's of the Public and Private Sectors
X. Pillar VI: Accuracy of Information on E–Security Incidents and Public–Private Sector Cooperation
XI. Pillar VII: Education and Prevention of E–Security Incidents
References
Glossary
Annex I. Risk Management: A Blueprint for Layered Security
Annex II. Authentication and Non-Repudiation
Annex III. E–Security in the Case of Wireless
Annex IV. New Regulatory Paradigm: Safe and Sound Transactions in an Open networked Environment
anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/08/2002 08:59 AM
To: cryptography@xxxxxxxx
Subject: anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
for eal 5/6 evaluation .... a semi-formal specification is
required. has anybody seen a fips186-2/x9.62 semi-formal
specification?
from common criteria ...
in the attached, TOE refers to "target of evaluation" ... for more
detailed definition ... see TOE in
http://www.garlic.com/~lynn/secure.htm
EAL5
EAL5 permits a developer to gain maximum assurance from security
engineering based upon rigorous commercial development practices
supported by moderate application of specialist security engineering
techniques. Such a TOE will probably be designed and developed with
the intent of achieving EAL5 assurance. It is likely that the
additional costs attributable to the EAL5 requirements, relative to
rigorous development without the application of specialized
techniques, will not be large.
EAL5 is therefore applicable to those circumstances where developers
or users require a high level of independently assured security in a
planned development and require a rigorous development approach
without incurring unreasonable costs attributable to specialist
security engineering techniques.
EAL5 provides assurance by an analysis of the security functions,
using a functional and complete interface specification, guidance
documentation, the high-level and low-level design of the TOE, and all
of the implementation, to understand the security behavior. Assurance
is additional gained through a formal model of the TOE security policy
and a semiformal presentation of the functional specification and
high-level design and a semiformal demonstration of correspondence
between them. A modular TOE design is also required.
This EAL represents a meaningful increase in assurance from EAL4 by
requiring semiformal design descriptions, the entire implementation, a
more structure (and hence analyzable) architecture, covert channel
analysis, and improved mechanisms and/or procedures that provide
confidence that the TOE will not be tampered with during development.
EAL6
EAL6 permits developers to gain high assurance from application of
security engineering techniques is a rigorous development environment
in order to produce a premium TOE for protecting high value assets
against significant risks.
EAL6 is therefore applicable to the development of security TOEs for
application in high risk situations where the value of the protected
assets justifies the additional costs.
This EAL represents a meaningful increase in assurance from EAL5 by
requiring more comprehensive analysis, a structure representation of
the implementation, more architectural structure (e.g. layering), more
comprehensive independent vulnerability analysis, systematic covert
channel identification, and improved configuration management and
development environmental controls.
Challenge to TCPA/Palladium detractors
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/10/2002 11:25 PM
To: Russell Nelson <nelson@xxxxxxxx>
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx
Subject: Re: Challenge to TCPA/Palladium detractors
small discussion of security proportional to risk:
http://www.garlic.com/~lynn/2002h.html#61 security proportional to risk
slightly related
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
also slightly related, both the tpm chips and various card chips are
similar ... some with eal3-high or eal4-high evaluation. however these
ratings are typically just for the chip ... or the chip with the
barest of software .... not the completely delivered operation
environment.
trying to get an EAL5-high or EAL6-high on the complete package
.... would include getting evaluation on things like any crypto (for
those chips employing crypto) ... which is a interesting whole 'nother
exercise. slightly related:
http://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
http://www.garlic.com/~lynn/2002h.html#71 history of CMS
http://www.garlic.com/~lynn/2002h.html#84 history of CMS
http://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition for eal 5/6 evaluation
nelson@xxxxxxxx on 8/10/2002 11:01 pm wrote:
Can't be done. I don't have time to go into ALL the reasons.
Fortunately for me, any one reason is sufficient. #1: it's all about
the economics. You have failed to specify that the cost of breaking
into the data has to exceed the value of the data. But even if you
did that, you'd have to assume that the data was never worth more than
that to anyone. As soon as it was worth that, they could break into
the data, and data is, after all, just data.
Ignore economics at your peril.
--
-russ nelson http://russnelson.com |
Crynwr sells support for free software | PGPok | businesses persuade
521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Challenge to TCPA/Palladium detractors
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 08/10/2002 11:40 PM
To: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx
Subject: Re: Challenge to TCPA/Palladium detractors
oops, finger slip that should be
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk
aka 2001h.html not 2002h.html ....
lynn.wheeler@xxxxxxxx on 8/10/2002 11:25 pm wrote:
small discussion of security proportional to risk:
http://www.garlic.com/~lynn/2002h.html#61 security proportional to risk
Feasability of Palladium / TCPA
Refed: **, - **, - **
From: Lynn Wheeler
Date: 08/12/2002 11:22 AM
To: Tim Dierks <tim@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: Feasability of Palladium / TCPA
there are two possible answers:
1) it just has to be at least as secure at the risks (doing something might
improve the situation so that some number of vulnerabilities ... but not
all ... are minimized).
2) one of the excuses for not spending the money on secure software ... as
opposed to the current process .... is it wouldn't improve anything because
everything else is insecure. so there is a huge chicken and egg situation
.... no single operation should do anything about security because the
hundred of other organizations that are involved in producing insecure
components are not doing anything about security
(nobody should do nothing because everybody else is doing nothing).
I've been railing about the buffer-overflow vulnerability every since we
did the vulnerability analysis for ha/cmp in the late 80s .... it is just
another on the list of things that need fixing also. some general stuff:
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#assurance
tim dierks.org on 8/12/2002 10:12 am wrote:
I haven't done an in-depth reading of available information of
Palladium/TCPA specifications, but my understanding is that there is a
private key stored in hardware and a contiguous chain of trust that extends
from the hardware/BIOS through the OS to an application, with each level
validating the superior levels; specifically, the hardware/BIOS validates
the OS as compliant, and then the OS validates an application's identity.
The OS then vouches for the application to the BIOS, giving the application
the ability to make indirect use of the hardware private key in order to
engage in application-level communication with an attestation of the
integrity of all levels (hardware, OS, application).
Here's my question: who thinks this can actually be made secure? Having
spent some time looking at such security issues, developing software, and
watching security alerts fly by for software, I think there's almost no
chance that the attestations made by the OS can be very secure.
Given the nature of PC software platforms, with the size, complexity, and
diversity of vendors, I think it is guaranteed that there will be software
bugs that will allow attackers to run rogue code inside another
application's address space or otherwise cloak themselves in another
application's trust attestation. The attacker can thus get access to
protected secrets or the ability to convince a remote system that they are
an authentic & secure software instance.
Does anyone not believe that there's not going to any buffer-overflow type
bugs in drivers for third-party sound cards that will allow an attacker to
execute code as some other application? And what can be done about? It's
certainly not viable to require dramatically more code review & security in
applications & drivers: I don't think Microsoft & Intel are willing to
sacrifice the economic viability of the platform on the throne of DRM. It's
also not acceptable to customers to require that all code running on the
platform be signed & authorized (unless you're willing to destroy the
industry of software developers who are not large enough or reliable enough
to get such signatures, including the entire open source industry). I don't
believe it's technologically feasible to design a software platform that
can reliably determine the complete chain of control resulting in an API
entry-point being called. (Among other things, you can execute an attack
without having your return address address on the stack.)
Bottom line, I don't think that TCPA or Palladium will be reliable enough
to really constrain those who wish to penetrate it. Given that, I don't
think that there will be as high a value put on the technology by vendors &
rights holders (since their stuff can be stolen by others anyway). If
there's not a high differential value to these architectures, then
presumably the market will not support a high differential price, and the
technologies will not see widespread acceptance.
- Tim Dierks
PS - I'm looking for a job in or near New York City. See my resume at
<http://www.dierks.org/tim/resume.html>
Overcoming the potential downside of TCPA
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/14/2002 04:36 PM
To: bear <bear@xxxxxxxx>
cc: Joseph Ashwood <ashwood@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: Overcoming the potential downside of TCPA
Just because some cars have anti-theft devices that can be defeated in
seconds .... doesn't make all auto anti-theft devices useless.
so you have currently have an environment that has no protection and
everything is totally wide open.
lets say a hardware chip that currently has no tamper resistance and a
whole infrastructure is put in place based on having security based on
a hardware chip. Hypothetically it eliminates allt the non-physical
attacks. however there are still vulnerabilities involving physical
attacks on the hardware components.
Would that be beneficial? Would it be helpful to eliminate all network
and electronic attacks leaving only physical attacks?
One of the issues is that some amount of the population actually has
some sensitivity for dealing with physical attacks. Part of the
current problem is many people don't have any experience dealing with
electronic and non-physical attacks. I would consider the elimination
of all electronic and network attacks as an interesting prospect.
So what does the world currently do about physical attacks.
Some organizations .... if they physical own the device and trying to
protect against outside attacks .... might put the device under armed
guards.
If it is DRM, where the chip is, in effect, acting as a proxy agent on
somebody else's behalf then there is issue about protection about
physical attacks by the person in possesion of the
device. Tamper-resistance just ups the cost of a succesful attack. One
could hypothesis the value of something that is always in excess of
the protection measures. .... i.e. security proportional to the risk;
aka ... regardless of the protection measures there could always be
some hypothetical value making it worth the cost of mounting an
attack.
The hypothetical DRM risk is possibly 90 percent of the infrastructure
(not single, here & there isolated copying .... copying being done
everywhere). Would some TCPA possibly both increase the percent of
authorized copies and reduce the unauthorized copies (i.e. a method to
reduce unauthorized copies to zero is by not publishing the works at
all). The issue isn't absolutely ruling out unauthorized copies
.... the issue is increasing the percent of authorized copies.
So hypothetically, the environment has reduced all the vulnerabilities
and attacks to attacks just on the physical chip. It is possible that
market forces could react to such an environment and opportunity. One
opportunity might be higher priced PCs that have chips evaluated at
EAL7-high with loads of tamper-resistance along with certain works are
only available on machines having the higher evaluated chips.
random mutterings about parameterised risk management:
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
http://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
http://www.garlic.com/~lynn/2000.html#46 question about PKI...
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
bear@xxxxxxxx on 8/14/2002 9:19 am wrote:
The problem with this idea is that TCPA is useless. For all the
useful things you are thinking of, you need TCPA plus an approved
key. The only way you are going to get an approved key is inside a
tamper-resistant chunk of hardware. If you should manage to extract
the key, then yes, you'll be able to create that CD. But the idea is
that you, the hardware owner, are not authorized to extract the
information contained in your own hardware. I find the idea of
"owning" something without having the legal right to open it up and
look inside legally dubious at best, but I'm no lawyer....
The idea is that you shouldn't get anywhere without hardware
hacking. The people doing this have decided hardware hacks are
acceptable risks because they only want to protect cheap data --
movies, songs, commercial software, whatever. They are sticking to
stuff that's not expensive enough to justify hardware hacks.
However, if this infrastructure does in fact become trusted and
somebody tries to use it to protect more valuable data, God help them.
They'll get their asses handed to them on a platter.
Bear
Overcoming the potential downside of TCPA
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/15/2002 02:41 PM
To: bear <bear@xxxxxxxx>
cc: Joseph Ashwood <ashwood@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: Overcoming the potential downside of TCPA
hum, i guess i somewhat view the situation somewhat in flux ... maybe
analogous to the period when there was a claim that only auto
mechanics should be allowed to drive automobiles .... and only
automobiles that required mechanics to drive them should allowed to be
built. The situation today is that while anybody could build their own
automobile from scratch, few actually do.
as to putting together reliable configurations ... i've had a little
experience ... possible you've heard of some of it.
there was this little client/server startup in the valley that was
interested in implementing server transactions ... with this emerging
technology that required some amount of vetting and maturing. during
the year that my wife and i worked with them on the implementation and
deployment they moved from menlo park to mountain view and changed
their name from mosaic to netscape .... the emerging technology is
sometimes referred to as SSL or HTTPS and the transactions they wanted
to do are sometimes now referred to as electronic commerce. Possibly
you have heard of some of this? Does Netscape, SSL, HTTPS, or
electronic commerce ring any bells?
some past integrity and security suggestions:
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything
no matter how much I wanted the industry to not allow operation of
systems that didn't meet certain criteria, I wasn't succesful.
thread somewhat analogous to this one:
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
http://www.garlic.com/~lynn/aadsm5.htm#asrn4
slightly related mumblings on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional to Risc
rant about maybe in a couple thousands years security engineering will
reach the maturity level of civil engineering for bridge building
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
How many people participate in the creation of the bridges and roads
that you drive on ... so that you could examine the safety of the road
bed before it is paved over?
bear@xxxxxxxx on 8/14/2002 9:54 pm wrote:
... wide ... open ... <<boggle...>> Do you even know what Kerchoff's
Principle IS?! Look, I've been trying to hold back on actual ranting,
but... but... you really don't get it, do you?
<rant mode ON -- sorry guys....>
On the contrary, I have one box with all the protection I want: it's
never connected to the net at all. I have another box with all the
protection that I consider practical for email and web use. Both run
only and exactly the software I have put on them, which I obtained
from sources trusted to me and which do not and CAN NOT require any
further interaction or authorization whatsoever to run their software.
I have selected software, on purpose, which denies someone who is not
me even the bare possibility of restricting my ability to run it at
some future time. I have the source code.
That is what I mean when I talk about trusted computing. I trust that
my software does what it says it does, is completely open to
inspection and verification by first, second, and third parties, and
cannot be denied to me at any point after I have come to depend upon
it, whether or not I have a net connection at the moment to interact
with its creators. I trust that I cannot be singled out remotely to
have a sniffer installed on my local machine through a backdoor. I
trust that code I can inspect at the level of machine instructions is
code that cannot keep secrets from me or forever conceal malign
intent. I trust that I cannot be forced to depend on any single
commercial software provider, whether it be for the OS or for the
"trusted" compiler which can, of course, come from only one source. I
trust that coercive "upgrades" done for the sake of incompatibility
with existing code, do not and cannot happen automatically given my
system configuration.
That is trusted computing sir, and TCPA/Palladium is a huge step
backward from it. Anything that runs ANY code that cannot be
inspected, or which keeps data that cannot be inspected, is running
code that cannot be trusted.
TCPA/Palladium does not provide trusted computing. At least not
computing that I can trust in the way I trust what I've got now. In
fact, from my POV, TCPA/Palladium look like ways to enable the running
of software which I CANNOT trust. Imagine my excitement at the
prospect.
This is a cryptography mailing list. Do we even want to count the
number of times commercial software providers have come up with some
crap and claimed it was secure, and been just lying to us? Do I have
to recount all the proprietary, snake-oil encryption systems that
relied for its security on not being inspected? Do I have to recount
the number of ways that unstudied security designers have given us
their best efforts and had them shot down by professionals in seconds?
Do we have to speculate about what can happen if the clowns who employ
them think they'll never be caught?! We've all been around the block
enough to know this by now:
Kerchoff was absolutely right. A hundred and twenty years since he
elucidated the Principle has not changed a thing.
NOBODY has the manpower or time to find all their bugs in-house.
If you can't inspect the machine code (and preferably the source) then
you are looking at something that is not and can never be made secure.
Now, you're talking about a system that gives people the opportunity
to HIDE THE CODE, and telling us that's security?! What the hell are
you smoking?! You are confusing real security mistakes with the
ability to DETECT real security mistakes!
<Rant mode OFF -- I'm getting too angry about this, I need to take a
break from this topic. ... >
Bear
TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/15/2002 08:49 PM
To: Adam Back <adam@xxxxxxxx>
cc: Joseph Ashwood <ashwood@xxxxxxxx>,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx
Subject: Re: TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
I arrived at that decision over four years ago ... TCPA possibly
didn't decide on it until two years ago. In the assurance session in
the TCPA track at spring 2001 intel developer's conference I claimed
my chip was much more KISS, more secure, and could reasonably meet the
TCPA requirements at the time w/o additional modifications. One of the
TCPA guys in the audience grossed that I didn't have to contend with
the committees of hundreds helping me with my design.
There are actually significant similarities between my chip and the
TPM chips.
I'm doing key gen at very first, initial power-on/test of wafer off
the line (somewhere in dim past it was drilled into me that everytime
something has to be handled it increases the cost).
Also, because of extreme effort at KISS, the standard PP evaluation
stuff gets much simpler and easier because most (possibly 90 percent)
of the stuff is N/A or doesn't exist
early ref:
http://www.garlic.com/~lynn/aadsm2.htm#straw
or refs at (under subject aads chip strawman):
http://www.garlic.com/~lynn/x959.html#aads
random evauation refs:
http://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
http://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition for eal 5/6 evaluation
adam@xxxxxxxx on 8/15/2002 6:44 pm wrote:
I think a number of the apparent conflicts go away if you carefully
track endorsement key pair vs endorsement certificate (signature on
endorsement key by hw manufacturer). For example where it is said
that the endorsement _certificate_ could be inserted after ownership
has been established (not the endorsement key), so that apparent
conflict goes away. (I originally thought this particular one was a
conflict also, until I noticed that.) I see anonymous found the same
thing.
But anyway this extract from the CC PP makes clear the intention and
an ST based on this PP is what a given TPM will be evaluated based on:
http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-PP-TPM1_9_4.pdf
p 20:
| The TSF shall restrict the ability to initialize or modify the TSF
| data: Endorsement Key Pair [...] to the TPM manufacturer or designee.
(if only they could have managed to say that in the spec).
Adam
--
http://www.cypherspace.org/adam/
draft-ietf-pkix-warranty-ext-01
Refed: **, - **, - **
From: Lynn Wheeler
Date: 08/16/2002 09:52 AM
To: <asturgeon@xxxxxxxx>
cc: "Denis Pinkas" <Denis.Pinkas@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: draft-ietf-pkix-warranty-ext-01
somewhat aside, note that most financial risk management has moved
past stale, static data ... even on a per transaction basis .... since
the exploits/attacks on such infrastructures started using
aggregation. the old-style "signing limit" checks attempted to manage
risk & liability on a per transaction basis .... but quickly found
that they were extremely vulnerable to aggregation risks. That is one
of the forces leading to online operation in the financial industry
(as opposed to an offline operation with trivial per transaction
limits and no support for online management of aggregation).
A similar model might be various kinds of automobile insurance with
per transaction limits .... however any aggregation risks tend to
happen over a long enough period that processing tends to occur in
"relative" real time (and they have been able to manage aggregation
risks ... if nothing else by canceling the policy).
The problem for the insurance industry is given the alternatives
between an offline paradigm and an online paradigm .... where the
offline paradigm with basically per transaction limits .... and an
online paradigm that can handle both per transaction and aggregation
limits .... the offline paradigm leaves them wide-open to aggregation
attacks/risks. The problem for a certificate is that the policy &
representation is static per transaction risk/limit ... and any
migration to an offline paradigm with both support for per transaction
as well as aggregation risk/limits obsoletes the requirement for the
certificate.
Somewhat analogous is the hardware token (as a credential) ... when
used purely in an offline mode, there have been all sorts of
aggregation risk. Typically the remedial action is to limit the per
transaction exposure to a very trivial dollar value .... as a
mechanism for attempting to bound the aggregation risk/exposure.
The problem for an indusrance industry risk managing in establishing
policy rates .... isn't the per transaction limit risk .... but what
is the worst case risk scenario for an offline paradigm with regard to
transaction aggregation. The certificate doesn't contain a dynamic
transaction count and/or any sort of dynamic value aggregation
.... and/or even idea of how many times it has been used ... which is
the unknown exposure facing the risk manager having to establish
policy rates aka when they look at the risk exposure for establishing
insurance rates .... it is the total risk exposure. A single per event
bound doesn't tell them anything unless they can also put a reasonable
bound on the maximum number of such events .... to arrive at the total
risk.
Smartcard in CD
From: Lynn Wheeler
Date: 08/31/2002 02:15 PM
To: ray@xxxxxxxx
cc: cryptography@xxxxxxxx, HugheJP@xxxxxxxx,
Michael_Heyman@xxxxxxxx, ptrei@xxxxxxxx
Subject: Re: Smartcard in CD
iso format/standard is not only thickness but also flexibility .... even
some proximity (iso 14443) cards have had problem in the past with
flexibiity standards because flex tests would stress the coils in the
plastic and cause the connection to the chip to break.
ray@xxxxxxxx on 8/31/2002 4:57 arm wrote:
Contactless smart cards typically have coils in the card and the
magnetic field is generated by the reader.
Capacitive coupling is an alternative but requires more precise
alignment and thus doesn't really provide a proximity/vicinity card
like inductive coupling does.
On-board batteries are hard to fit on an ISO-format smart card but
maybe with the new ultra-thin batteries that's no longer the case.
Batteries are perhaps more suitable for a CD.
draft-ietf-pkix-warranty-ext-01
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/02/2002 01:38 PM
To: Denis Pinkas <Denis.Pinkas@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
asturgeon@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: draft-ietf-pkix-warranty-ext-01
In addtion to insurance premiums proportional to risk
http://www.garlic.com/~lynn/aadsm12.htm#20draft-ietf-pkix-warranty-ext-01
There are actually a couple of issues:
a) security/insurance proportional to risk. in the online world
... the RP/merchant may get a surcharge per transaction that pays for
insurance on per transaction basis. they may also have one-time
disaster insurance ... that is sort of independent of the number of
transactions ... but represents some total value that is at risk
b) the entity at risk pays for the insurance. typically the business
arrangement is between the CA and the entity being certified. if it is
a merchant certificate then the CA can charge a little bit more for
the insurance to cover damages where the merchant might get sued. if
it is a consumer certificate .... the consumer is being charge but
typically the merchant is still the one at risk; not the consumer
(this is because there are special provisions favoring consumers in
retail transactions .... this wouldn't apply between two equal parties
in commercial transactions). Ignoring for a moment the issue of
whether (offline paradigm) certificates are needed in the online
world, there is a separate issue that the entity primarily at risk is
not party to the CA/consumer business transaction. There is nominally
no direct business relationship between the CA & the merchant in the
case of consumer certificates .... so it is difficult for a merchant
to establish liability (possibility other civil legal issues) against
the CA. Difficult for a merchant to sue a consumer because of CA
liability to the consumer.
CAs either have to
1) convince consumers that certificates are good for something that
consumers have at risk (say identity theft) for which the CA can
justify charging the consumer extra to cover the cost of doing
business as well as ancillary things like insurance ... or
2) CAs have to revamp the business model so that there is a
contractual relationship between the CA and the RP ... and be able to
charge on the basis of that ... or
3) get gov. to pass mandated certificate requirements.
now ... if
1) if consumers (or any party) aren't at risk ... it is hard to get
them to (directly) pay anything
2) if a contractual relationship between CAs and RPs can be fabricated
.... then you are likely to have relying-party-only certificates
.... the RPs pay either directly or indirectly (so that there is a
contractual relationship with the CA on which money flow can be based)
... the RPs will pass on the cost for relying-party-only certificates
to the consumer .... but it is a business solution to match the money
flow with who is at risk and the contractual relationships. The
downside here is that it is trivially possible to show that
relying-party-only certificates in an online, transaction world are
redundant and superfluous. This establishes some basis for civil
litigation.
3) if you can get a gov. to pass bills mandating something ... then
you can eliminate any civil liability issues with the contractual
relationships and money flow not matching parties at risk.
I believe there has been lots of past discussions regarding the
difficulty in the commercial world of establish money flow & risk with
the RP in a standard CADS paradigm (the RP being at risk but original
CADS business model had no contractual relationship between the CA and
the RP). I believe the FED GSA PKI stuff has tried to resolve this by
contorting the business model that the contractual relationship is
between GSA and the CAs .... and that the CAs are providing
(relying-party) certificates to end-users. CAs may levy a surcharge on
the end-users for the certificate issuing ... but the business
relationship is not between the CA and the end-user .... it is between
the CA and GSA (the relying party). Note that since the business
relationship is between the CA and the GSA, the contract(s) call out
the warranties and liabilities. In this case, certificates would be
considered a service provided and independent of the contract
documents and the specifications of T&Cs, warranties, liabilities and
things like insurance.
The next step would be to get some kind of legislative bill passed
that mandates such certificates .... even when it can be proven that
they are redundant and superfluous in an online world.
random refs on relying party certificates:
http://www.garlic.com/~lynn/subtopic.html#rpo
denis.pinkas@xxxxxxxx wrote:
Alice,
I concur with many of the arguments raised by Anders. It is very scarce, but
this time it happened, thanks to your draft. :-)
I believe that sufficient arguments have been raised against the progression
of this draft, as it stands, which does not even explicitly states, for a
naive reader, what the warranty is about.
The warranty is concerned with the liability of the CA, more precisely, only
errors made by the CA personal or attributed to the CA during the management
of the certificate, e.g. at the time of registration of the subject, when
issuing the certificate, when handling revocation requests or when making
available revocation status information.
Regards,
Denis
10 choices that were critical to the Net's success
From: Lynn Wheeler
Date: 09/09/2002 03:19 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: dcsb@xxxxxxxx
Subject: Re: 10 choices that were critical to the Net's success
a couple additional points
1) arpanet had a single homogeneous implementation using the IMPs. the
internal network effectively had gateway function in every node and
wasn't subject to the arapnet limitations of a homogeneous
network. this wasn't corrected until 1/1/83 switch over .... where it
finally got "internet" and the idea of gateways that could handle the
interoperability between heterogeneous environments. at the 1/1/83
switch over there were less than 255 nodes. around late '84 there
were: http://www.garlic.com/~lynn/2002k.html#26
2) i would consider the AUP a temporary, transient issue. i would
claim more significant was effectively huge amount of unused capacity
(in places like dark fiber) and the owners of this capacity to make
significant excess resources (over and above what was actually called
for in NSFNET1/NSFNET2 backbone) as an incubator environment to help
evolve new, bandwidth hungry applications. I would assert that the
provision of those resources were more significant than the AUPs. Some
NSFNET backbone:
http://www.garlic.com/~lynn/2002k.html#12
extract of email i got announcing the award and asking to participate
http://www.garlic.com/~lynn/2000e.html#10
3) lots of people ignored the gov. and other large structured
organizations with regard to GOSIP and other OSI mandates.
4) IETF standards policy of needing two interoperable implementations
for standard progression. The whole ISO/OSI seemed to go forth with no
concept whether anything was actually implementable in any practical
sense.
5) large number of educational institution networking nodes in bitnet,
earn and other networks that addition of gateways could significantly
increase total network coverage. a earn specific ref from 1984:
http://www.garlic.com/~lynn/2001h.html#65
misc. other refs:
http://www.garlic.com/~lynn/internet.htm#0
http://www.garlic.com/~lynn/subtopic.html#networking
rah@xxxxxxxx on 9/9/2002 11:29 am wrote:
http://www.siliconvalley.com/mld/siliconvalley/business/columnists/4029770.htm?template=contentModules/printstory.jsp
Posted on Sun, Sep. 08, 2002
10 choices that were critical to the Net's success
By Dan Gillmor
Mercury News Technology Columnist
In our modern, corporate culture, the rise of the Internet is a happy
accident. In its roots and growth, says Scott Bradner, the Net never had a
business model.
How did technologists, government officials and a host of other early
players turn something with no obvious business model into a system that
has become so intrinsic to the new century? A series of decisions proved
critical -- choices that helped turn data transport into a commodity
business and put the power in users' hands, not in the centralized
telecommunications companies' controlling grasp.
At a telecom conference in Massachusetts last week, Bradner, senior
technical consultant at Harvard University and a longtime leader in the
formation of Internet standards, listed 10 crucial decisions along the way.
(You may have other candidates; send them to me and I'll list them on my
Web page). Here are Bradner's picks:
1) Make it all work on top of existing networks. Designers deliberately
didn't try to build a single, new über-data network -- it was about
``networks, not a network,'' Bradner observes. This meant supporting
multiple network types by putting a simple set of rules, now called the
Internet protocols, on top. This added layer was wide open for innovation,
not controlled by a few players.
2) Use packets, not circuits. Telephone networks open a circuit from one
phone to another, keeping the connection open until the call is ended. The
Internet splits messages into little packages called packets, which are
sent to their destination by various routes and at various times. This was
a radical idea at the time, but it has been one of the qualities that makes
the Internet so basically reliable and resilient under stress.
3) Create a ``routing'' function. Stand-alone boxes along the way from
point to point make instant decisions on what route to send each packet by,
reacting to failures in the networks. Again, this was a decentralizing
function that enhanced reliability.
4) Split the Transmission Control Protocol (TCP) and Internet Protocol
(IP), which are generally used together in much of what we do on the Net
and are called TCP/IP. Originally they were meant to be tied together in a
single service designed to guarantee that the stream of data would get to
its destination complete and in perfect order. To do this, however, would
have given network services far less flexibility. IP by itself offers an
unreliable but still enormously valuable service, simply sending the
packets through the network without checking to see if they all get there.
TCP makes sure, among other things, that they actually do get there. So an
application can use TCP if it cares most about reliability, while another
application can use IP (and other protocols) if it's more concerned with
timeliness -- such as an Internet phone call -- where losing a few packets
matters much less than getting most of the data there on time.
5) The National Science Foundation (NSF) funds the University of
California-Berkeley, to put TCP/IP into the Unix operating system
originally developed by AT&T. Berkeley thereby created a full but low-cost
network operating system, along with a full suite of network applications,
that computer start-up companies flocked to use in their boxes. It was,
says Bradner, ``a way to get into the networking game without spending a
lot of money.'' So it spread fast.
6) CSNET, an early network used by universities, connects with the ARPANET,
the Internet precursor network operated by the Pentagon's Advanced Research
Projects Agency. ARPA funded much of the early technical work on what later
became the Net. ARPANET use had been restricted solely to government-funded
individuals. The connection was for e-mail only, but it led to much more
university research on networks and a more general understanding among
students, faculty and staff of the value of internetworking. When students
graduated, they sought employers that had the technology.
7) The NSF requires users of the NSFNET to use TCP/IP, not competing
protocols. This decision about the NSFNET, which was originally created to
connect supercomputer centers, forced wider availability of the TCP/IP
protocol, and helped prevent a wasteful ``proliferation of miscellaneous
transport protocols for the Internet,'' Bradner says.
8) International telecommunications standards bodies reject TCP/IP, then
create a separate standard called OSI. TCP/IP, remember, was designed as a
low layer on top of which other applications, such as e-mail, would be
created. OSI was carrier-centric, a suite of protocols that included things
like e-mail. Had TCP/IP been accepted and then co-opted by the
international groups and telecom companies, things we now take for granted
might not have appeared, or might have been under central control. One the
fundamentals of the Net is we can create new protocols on top of IP, as Tim
Berners-Lee did to create the World Wide Web, says Bradner -- ``and we
don't have to have permission of the carriers to do that.
9) The NSF creates an ``Acceptable Use Policy'' restricting NSFNET use to
noncommercial activities. Although this rule grew blurry, it was largely
heeded despite fierce criticism. The result was an incentive to create
commercial network providers. The commercial providers created a huge
business of long-haul ``backbone'' and local carriers upon which the
Internet relies today.
10) Once things start to build, government stays mostly out of the way. If
the Internet suffered from a lack of regulation, Bradner says, it was ``a
good suffering'' for all of us.
-----------------
R. A. Hettinga <mailto: rah@xxxxxxxx>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 17 Sep 2002 16:35:08 -0600
To: jon@xxxxxxxx
Subject: Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
Cc: Adam Shostack <adam@xxxxxxxx>,
cryptography <cryptography@xxxxxxxx>
At 01:07 PM 9/17/2002 -0700, jon@xxxxxxxx wrote:
As far as I know, banks assume that a certain percentage of their
transactions will be bad and build that cost into their business
model. Credit and ATM cards and numbers are as far from secure as
could be, far less secure than somebody doing online transactions from
a Wintel machine on an unencrypted connection, let alone an encrypted
one. Until somebody takes full advantage of the current system and
steals a few trillion dollars in one day, the problems are easier to
deal with than a solution. Until that happens, there's no reason for
banks to go through the pain of dealing with or requiring Pd.
-Jon Simon
note that EU finread standard attempted to address some of this. an
external (secure, finread) token acceptor device with secure display
and secure pin entry. The hardware token is used to "sign" the
(financial) transaction .... PIN code is entered into the finread
device and goes directly to the hardware token (w/o passing thru the
PC). Critical pieces of the transactions passes thru the finread
device on the way to the (signing hardware token) and is displayed on
the secure display ... which then requires the PIN to be entered to
confirm the transaction.
There is the issue of 3-factor authentication
something you have (hardware token)
something you know (pin)
something you are (biometrics in addition to &/or in place of PIN)
besides the straight-forward use of signatures to authenticate the
source of the transaction ... there is the nominal legal requirement
associated with physical signatures ... i.e. did you intend to sign
what you signed aka is what you "see" what you signed ... and do you
confirm that you actually want the hardware token to sign what you
"see".
A lot of digital signature seems to address the technology part of
authentication ... and then sometimes (just because the term
"signature" is used as part of the description of the technical
procedure) that all technical implementations of the process referred
to as "digital signature" is legally equivalent to "physical
signatures" (even when no aspects of intention have been satisfied).
random past finread & intention posts:
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/2000.html#0 2000 = millennium?
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
http://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2001f.html#39 Ancient computer humor - DEC WARS
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#46 Big black helicopters
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002l.html#26 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#28 Two questions on HMACs and hashing
Cryptogram: Palladium Only for DRM
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 17 Sep 2002 16:40:53 -0600
To: daw@xxxxxxxx (David Wagner)
Subject: Re: Cryptogram: Palladium Only for DRM
Cc: cryptography@xxxxxxxx
At 06:02 AM 9/17/2002 +0000, David Wagner wrote:
I wasn't thinking of pure software solutions. I was thinking of a
combination of existing hardware + new software: use the MMU to provide
separate address spaces, and use a secure VM or OS kernel to limit what
those processes can do. As far as I can see, this can provide just as
much protection against viruses for your bank account as Palladium can.
In general, with software and existing hardware working together, I
suspect we can already do everything Palladium can do, except for the DRM
and related applications founded on taking control away from the owner
of the machine. Maybe I'm missing something. Still, it seems to me that
Palladium would much more compelling if it left out the tamper-resistant
chip and gave up on the semi-coercive DRM-like applications.
couple refs to multics study
http://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ?
I-D ACTION:draft-ietf-pkix-usergroup-01.txt
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/03/2002 05:46 PM
To: Michael StJohns <msj@xxxxxxxx>
cc: anders.rundgren@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
The bit strings are essentially r/o (typically stale and significant
subset) of trust information in some sort of trust repository.These
trust bit strings were originally designed for use in offline
environments where there was something inhibiting the access to the
actual trust repository. They can currently be useful in environments
where it isn't worthwhile to know the actual timely &/or aggregated
information ... for instance you don't need to know things like
whether your online account is active, your have sufficient funds in
your account and/or you have exceeded your credit limit (aka useful
for low or no value operations).
the scenario is somewhat similar to the credit card industry of the
'60s that was non-electronic and offline. In the '70s, the online
economics was sufficient that it allowed a direct transition to
electonic and online (with some residual non-electonic/offline
lingering on). The certificate actrivity of the '80s was essentially a
paradigm step backwards in time ... to the '60s ... but with a offline
electronic ... rather than a offline non-electronic.
special purpose types of certificate are in effect the same or very
similar to the relying-party-only certificates that various
financial (and other) institutions were making use of by at least the
mid-90s. However, it is trivial to show that for any kind of value,
online operation the relying-party-only certificates are redundant and
superfluous (again leaving just the domain of offline, low/no value
operations).
misc. past r-p-o certificates references:
http://www.garlic.com/~lynn/subtopic.html#rpo
and of course ... the misc postings on end-game of why eventually TTPs
would even be issuing server domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
michael stjohns on 10/3/2002 3:44 pm wrote:
A 100% outsourced PKI should also be able to generate certificates which
use Subject and IssuerAltName extensions for at least the specified name
forms (e.g. RFC822 and DNS). This is just another plugin, and if it gets
into the normal PKI specification, a 100% outsourced PKI should be able to
issue this type of certificate. Its not a reasonable argument to make that
because it wasn't specified before no one will implement or use it. If it
doesn't have sufficient functionality, or breaks something - that's the
argument I'd actually like to hear.
Also, certificates are just bit strings - I don't need or want to use the
same certificate over and over again to access different resources. That
requires way too much centralization. Let me give you an example: Should
the same certificate I use to access local company resources be the same
one I use to make purchases on the internet which get charged to my Visa
card? I hope not. Let's look at the trust relationships. In the former,
I need a trust relationship with my local sysadmin who also has a trust
relationship with the local resources. By virtue of his/her position he
can establish a transitive trust relationship between me and the resources
by issuing me a certificate. In the Visa case, I have a relationship with
Visa as does the merchant (the transaction Acceptor). We both have
credentials issued to us by Visa which allow us to participate in a
commercial exchange under Visa's rules. The acceptor doesn't need to know
who I am, it just needs to know that Visa accepts me (or rather the holder
of the certificates private key) as someone who has a trust relationship
with Visa for the purpose of commercial exchanges of a particular type. I
don't need a global identity for that set of transactions. And indeed, a
global identity has all sorts of privacy issues.
I guess what I'm saying is that I'm not sure why paying Verisign to issue
client certificates makes a lot of sense.
Employee Certificates - Security Issues
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/04/2002 07:31 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Employee Certificates - Security Issues
there were (at least) 2-3 reason for relying-party-only certificates
(basically only an accont number and a public key .... and no other
information)
1) privacy .... even just a person's name (and no other information)
is a serious privacy concern for retail financial transactions .... EU
directive that electronic retail financial transactions sould be as
anonomous as cash .... any personal information in a certificate is
major privacy issue.
2) liability .... your point ... that they wanted absolutely no
misunderstanding that the certificate would convey or imply anything
... the certificate was purefly a convienient bit-string required for
conforming to COTS digital signature software (see #3)
3) most COTS easily available digital signature software required a
certificate to exist ... even tho the actual business process
transactions were online ... not offline ... so from a business and
information flow ... the existance of a certificate was redundant and
superfluous ... purely an artificial artifact of the COTS digital
signature software that was easily available.
insitutions doing online transactions between themselves and their
member entities (clients, account holders, employees, etc) will
typically directly refererence the actual trust repository .... a R/O,
stale, subset copy of such information is typically only useful for
offline, low/no value operaions (by definition, most value operations
easily justify access to near real time or aggregated data).
A simple example would be a supplier/customer relationship would be
embodied by an account record representing various things typically
might be found in contract T&Cs ... possibly limits, payment terms,
negotiated prices, volumes, etc.
Similar information might be for employees ... they could be given a
hardware token ... that for some no/low secure external doors
.... operate the unlocking of the door in offline mode (the existance
of the token is sufficient for unlocking low-security external
door). Higher security access is likely to migrate to things like
online door access operation that supports being able to fire & revoke
access in real time.
anders.rundgren@xxxxxxxx on 10/3/2002 11.25 pm wrote
"I, the Company"
When employees have been equipped with digital certificates,
linked to the organization, interesting things happen: Employees
can now sign on behalf of the organization. Due to the absence of
a generally understood X509 "authority" system, you can probably
sign whatever you want and an external receiver is meant to believe
that you have the right to do it. This is probably as far from an
organization-adapted solution one can get (as organizations want to
have control over their internal and external actions), and is an
indication that this scheme is not suitable for large-scale deployment.
As a countermeasure one could think of having an
"authority control server" checking and logging all employee actions.
Unfortunately that does not work; if you have an employee certificate
you can fairly easy create messages that to receivers, look perfectly
valid without going trough the authority server.
Summary: An architecture that is fundamentally broken.
And, yes, I forgot to mention costs, privacy, archiving, and
the multitude of roots that you have to cope with.
Comments?
Anders Rundgren
Employee Certificates - Security Issues
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/04/2002 07:54 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Juergen Brauckmann" <brauckmann@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: Re: Employee Certificates - Security Issues
there are two other scenarios given in
http://www.garlic.com/~lynn/x959.html#aads
it is a traditional PKI but either
1) the Certification Authority is issuing a relying-party-only
certificate ... however it is interested in saving bandwidth. It
realizes that the certificate will only be used in valid transactions
with the institution and that PKI allows for cached certificates
.... so it pre-caches the certificate original in the respective
account record and saves the bandwidth of sending a certificate copy
back to the key-owner (and eliminates the key-owner ever having to
attach the certificate copy to a transaction and return it to the
certifying/relying party ... that already has pre-cached the
certificate original and therefor returning the certificate copy to
the entity that has the certificate original is redundant and
superfluous)
2) the Certification Authority is issuing a relying-party-only
certificate ... however it is interested in saving bandwidth. It
realizes that all the fields in the certificate are already present at
the relying/certifying party and that there are PKI standards for
compressing certificates. Using the simple principle of knowledge
compression, it is possible to "compess" from the certificate fields
that are already present at the certifying/relying party. As a result,
the certifying/relying party compresses all duplicate fields from the
certificate resulting in a zero byte certificate. The key owner
receives this zero byte certificate and attaches it to every
transaction.
Now as to the storage of the original certificate at the
relying/certifying party. Typically something like ASN.1 encoding is
used for encoding the certificate ... primarily for transmission and
interoperability. However since the relying/certifying party is just
recording the information .... after either 1) or 2) above ... the
certifying party pre-decodes the ASN..1 encoding prior to storing the
information (either 1) the original certificate or 2) the individual
fields).
anders.rundgren on 10/4/2002 3:15 am wrote:
No, the Internet-bank model does not require any "particular" client-
certificates, it is enough that you are recognized/accepted/trusted as
no traces of client certs ever leaves your bank. You can use a "civil"
ID-card with no information about bank, employment etc.
A major Swedish bank is buying such from a TPP to take a example.
So could other organizations do as well.
Employee Certificates - Security Issues
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/04/2002 01:32 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, "Guida, Richard [JJCUS]" <RGuida@xxxxxxxx>
Subject: Re: Employee Certificates - Security Issues
the other way of looking at it ... is most certificates have been
assumed to be certifying something that an institution already knows
(or has been obtained by a TTP for use by other, relying parties).
In the case of a relying-only-party certificate ... where the
institution typically already has a business process in place that has
vented the information and it is stored in something like an employee
record or a client record .... or some similar type of record
.... transposing a subset of that information into a stale, static copy
of such a record (aka into a certificate) ... for their own use
.... is frequently redundant and superfluous and an artificial
artifact of varous COTS digital signature software that they might be
using.
A r-p-o certificate needs little else than a reference to the account
record where the real, up-to-date information is stored ... and such
reference is aleady typically carriend in the main body of the signed
message and it is redundant to also carry it an additionally appended
separate signed message (called a certificate). Additional
information (other than a record locator) frequently can be construed
as a serious privacy issue (especially in consumer/retail setting)
A non r-p-o certificate ... for others use, is where some additional
information might need to be carried ... but that opens up the whole
bag of worms regarding privacy and liability and what if any
(liability) commitment is the certifying body making with respect to
the information carried in such a certificate ...
in otherwords
1) can i trust my own information that might also be carried in a
redundant and superfluous r-p-o certificate
2) what reason, if any, should anybody else trust any information
carried in a certificate (and if they were to construe any such
information in a financial/business setting is there implied
liability)
one way of making sure there is no implied reliance on a r-p-o
certificate and therefor no implied liability (and/or even privacy
exposure) ... is to not actually every transmit such a certificate
... if it never actually exists ... then it is hard for other parties
to claim reliance (&/or liability).
anders rundgren on 10/4/2002 10:24 am wrote:
Richard,
I think you have mostly misinterpreted my messages.
Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer. This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.
What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc. It is a
smart as giving the entire work-force company credit-cards.
Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages. In the same way as there is not a single bank in the
world that does this either. And this fact is completely independent
of the availability of client-side PKI.
Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.
Anders
Employee Certificates - Security Issues
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/07/2002 08:01 AM
To: "Särs, Camillo" <Camillo.Sars@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
"Särs, Camillo" <Camillo.Sars@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"Guida, Richard [JJCUS]" <RGuida@xxxxxxxx>
Subject: RE: Employee Certificates - Security Issues
this is also been discussed in the context of contracts and other use
of "paper" signatures as "intent" .... did the person "intend" to
perform the signature in the sense that they also "agreed" to the T&Cs
of the thing that was signed. a digital signature can be interpreted
as conveying much less than a paper signature (legally; in the sense
that it doesn't actually imply all the stuff that a paper signature
implies). the use of the term "digital signature" with the word
"signature" being used may create semantic confusion for some
automagically equating digital signature with manual/paper signature
.... just because the word "signature" appears in both terms. the
concepts of intention and agreeing then is also involved in
non-repudiation .... aka my machine may have signed a message ...
for authentication and integrity purposes .... but my machine doesn't
have authority to agree/approve terms of contract that may been
contained in the body of a message.
some past threads on intent &/or non-repudiation:
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
ht