Ah,
So we select a discovery application, once we recognise a std ATR, rather
than a MF/EF/DF ISO file system. Then we GET/PUT the object-file-store
hosting application data, and object data - rather than READ/WRITE records
in ISO files. ok....
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. 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.
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 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
