Peter Williams wrote:
Ah,
So we select a discovery application, once we recognise a std ATR,
rather than a MF/EF/DF ISO file system.
Yes, thats what it looks like NIST has defined for the PIV. So
multiple vendors can can provide cards with their version of the PIV
applet.
Then we GET/PUT the
object-file-store hosting application data, and object data - rather
than READ/WRITE records in ISO files. ok....
Correct.
We for PIV, we do a funky GET/PUT for TLV objects, renamed by ISO 8824
tagging, that sort of map onto interface discovery ids, and a PKCS#15
stream (which has only context tagging), but which all uses ISO file
system acls, acl management, and logical channels to control
host->applet security.
Yes, but the NIST PIV is very specific about what objects there are
on the card, and what the ACLs are for the objects. The NIST 800-73
is desigend to provide interoperability for the use of the card,
but not nessesarily on the administraiton of the card, leaving
up to the vendors to provide the initialization/personalizsation
with their card administration packages.
This contrasts with simply reading a PKCS#15
stream from an ISO file system over SCP02015 (remember the ISO files
were admittedly not designed for streams), or interact with an applet
supporting PKCS#15 stream navigation.
What the OpenSC code does is to in effect to make cards look like
it has a fixed pkcs#15 file system, which allows the use of PKCS#11
on top of this to use the X.509 Certificate for PIV Authentication
and its private key from PKCS#11 applications, like browsers or
Kerberos PKINIT.
So, assuming that the PIV design concept is to put the semantics of
PUT/GET now into the host/TPM driver, rather than in an ICC-side applet
for navigating the PKCS#15 stream, we make a giant step backwards
I agree, its looks like a step backwards. For example if an object
was never added to the card, it is not obvious what the get data should
return. But the PIV is a specific applet with specific objects it is
designed to support. You don't get to add your own objects, at least
not into the PIV applet. You could have other applets on the card
with other data, as well as a PKCS#15 file structure.
in
favor of yet more driver hacks, per card (discovery applet). Control
over end-end process interaction does however pass to the TPM however...
which is probably the (unstated) point of USG's design concept - to
ensure the national id card works with the TPM-based secure storage
control, to control a core's functional set arming, motherboard bus
enumeration discovery beneath the Intel ACPI, etc
And who was it who said that the European design concepts were
complicated, and unweildy?
----
having said all that, been looking at some PIV hardware prototypes.
25mAh rechareable battery-backed always on card via USB-enabled 7816-1
module, with chip on flex micro manufacturing, with buttons,
flexi-display for OTP, emulated swipe strip, and Mifare contactless
capaility via internal antenna conenctivity into the back of the die.
Nice USB-SIE enabled AVR-based 144k ROm, 144k eeprom for NSA's javacard
silos, with 6k RAM.
Default Applets should come with RSA's KIP, for configuring the OTP
device over the wire ,for different C/R schemes, and to resync the
temp-sensitive clock.
All in all, software + hardware, its all very complicated... leading
edge... and at risk, becuase of those facts alone.
From: "Douglas E. Engert" <[EMAIL PROTECTED]>
Reply-To: MUSCLE <[email protected]>
To: MUSCLE <[email protected]>
CC: Peter Tomlinson <[EMAIL PROTECTED]>
Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
Date: Wed, 22 Mar 2006 15:51:14 -0600
Scott Guthery wrote:
Just as a note in passing, the ISO/IEC 7816-4 GET DATA and PUT DATA
commands for reading and writing TLV data objects do NOT require a file
system. The PIV card application is an example of this approach.
And the PIV responds to a select of "A0 00 00 xx xx 00 00 10 00"
where NIST published on 10/6/2005 that xx xx is 03 08
See NIST 800-73-1
OpenSC has some code to use the PIV cards, usable with PKCS#11
applications.
Cheers, Scott
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Shawn Willden
Sent: Tuesday, March 21, 2006 5:16 PM
To: [email protected]
Cc: Peter Tomlinson
Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
On Tuesday 21 March 2006 14:38, Peter Tomlinson wrote:
There is provision in ISO/IEC 7816 for a card to identify itself in
several ways, but the majority of card suppliers either do not encode
the necessary information or encode it inadequately - or it gets
changed
to something else during personalisation. Typically the ATR may be the
starting point, or there may be extended information in an ATR File -
and there may also be a DIR file giving a directory of card
applications. (EMV of course has its own method of application
selection.)
GlobalPlatform also has provision for ID information, using data
objects
stored at the MF level.
Both of which require a 7816 file system (or enough of one, anyway). As
more and more Javacards are deployed, fewer cards have a file system :-/
We are still in the mindset that thinks bytes are extremely expensive,
and we need to get out of that and do the job properly.
What's funny about that is I've seen one system that fires literally
dozens of APDUs at a card in an attempt to determine what is on it...
it would
take far fewer bytes to query a file structure.
Shawn.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
