I just reread FIPS-201-1-v5, per request. I learned absolutely nothing, not
one iota of info, about GET/PUT custom storage semantics, or PKCS#15
"names".
So, I looked around and found
http://csrc.nist.gov/publications/nistpubs/800-73/NamespaceManagementPIVDataObjectsv1_1.pdf,
which seems a bit more on topic.
Here is the guts:
"The PIV Card Application and each of the PIV data objects are provided with
unique
names from controlled and managed sets of names called namespaces. There are
four
namespaces defined in SP800-73:
- Registered Identifier (RID) namespace for labeling PIV card applications
- Object Identifier (OID) namespace for addressing PIV data objects at the
Client
Applications Programming Interface
BER-TLV tag namespace for addressing PIV data objects at the Card Command
Interface
Key References
These namespaces are controlled and managed to assure interoperability of
PIV cards
across all PIV programs."
In terms of GET/PUT, lets assume we are focussing on " BER-TLV tag
namespace for addressing PIV data objects at the Card Command Interface". We
note the concept of a "PIV application domain" on PIV cards. Other domains
are implied to exist, with other namespace policies/registrars.
We note the application domain has one or more card applications, one of
which is known as the
"PIV Card Application" ( as described in the April 8, 2005 version of
SP800-73). We also note that "NIST will also provide AIDs for other card
applications in the PIV application domain.". So, in short, there are
several govt applets in the works...each using the same naming/registration
policy for datums. (Wonder what they are!?)
Now, we know there is a "Card Capability Container", referencing "PIV Data
objects" - denoted in client API using OIDs. The PDUs use tags, however,
from another a (related?) name space.
So, lets look at the wire format - for PDUs. "The initial release of SP
800-73 uses two-byte BER-TLV tags for the PIV data objects. ...All the PIV
data objects that appear on the card edge are Application Data objects" - in
the style of 8825 T-encodings (from TLVs). However, We also learn that the
tags, when they identify constructed TLVs , the members of the construction,
however, not NOT 8825 conforming... Wow. So, std TLV decoders for
constructors wont work... . One lib for X.509 constructed TLV object
decoding, another for the PIV data object. Hmm.
Don't suppose the Y, Z nodes from the oid, become the APDU's tag value
(subject of course to 8825-multi-byte encoding of tag ids), by any chance ??
We do know that Y and Z are infact GSC-IS Container identifiers, another
registrar of ids for value type, that get wrapped in the NIST oid for the
client API.
So Im guessing, now, that the container "object" contains a list of (2-byte)
contained-datum identifiers denoting those PIV data instances present in the
object store within the eeprom that the chip firewalls for the "PIV Card
Application" instance)
Perhaps this all means, in code, that:
1. the OID form of the GSC-IS 2 bytes identifier of the datum is used at the
client API.
2. the 8825 multi-byte encoded form of the 2 bytes is used a tag, for
GET/PUT PDUs to wire-represent the TLVs per the PIV data model (noting
oddities for constructed values, however)
3. the 2 bytes id are stored as a 2 bytes id in the container object, used
insome kind of value-schema wire-time byte verification?
ok. I think I get it. (Reading between the lines!)
Ok. back to name forms, now someone invented a scheme for "Key references"
(see section 5). Lets guess! They wont be (a) oids (b) 8825 tags (c) 2 byte
GSC-IS Container identifiers. They will be something else! Lets see:
Well, key references are "custom byte value", from some referenced table.
But the algoirithm identifier for that key is an OID ( i infer). Did 2 byte
GSC-IS Container identifiers get defined for algorithms, and then the 2
bytes are mapped into NIST registered oids (like for PIV data), to define a
new PIV-style oid for all the usual algorithm ids?
Then, there are non PIV-data objects, that may or may not participate in
this naming framework (container objects, GCS-IS registrations of contained
datums, NIST OIDs wrapping the registered 2 byte values, PDU tags
constructed (pun) from the 2 byte values?).
(Question to self, if non PIV-data objects do participate in this general
naming scheme, MUST their wire protocol use GET/PUT?)
Ok. still no mention of GET and PUT in relation to PIV named objects in
PDUs. Peter is beginning to get worried!
Lets go on, and review NIST Special Publication 800-87, Codes for the
Identification of Federal and Federally-Assisted Organizations":
"This standard data element also may be used for interchange of
identification codes assigned to a set of similar items, but only if an
organizational indication is included as part of the coding structure.
Examples of sets of items which could employ organizational-indicative
identification codes are: the Federal Agency Smart Credential Number
(FASC-N) that is required to be included in the FIPS 201 Card Holder-Unique
ID (CHUID)"
Ok more names, more registation authorities, all concerning the user's
unique id _value_ (that is store on card in a PIV data type, let me guess!),
and the organizational components, thereof. By chance, these happen to be a
2-btye value, also. This is presumably a value (of the CHUID type?), which
is stored as a PIV data, which is denoted in the Container object as a 2
byte field, but which is tagged on the wire using 3 byte tag encoding (but
watch out for those constructed non 8825 conforming CHUIDS, which have
signatures on them, apparently, making them "strong names" (to use a .NET
term)), which is referenced in the API as a 9 byte OID (reusing the 2 byte
as Y, Z elements of the NIST-registered OID).
Ok. at least this could be making sense, now! Still no GET/PUT discussion.
Ok. on to the next document! NIST Special Publication 800-85, PIV Middleware
and PIV Card Application Conformance Test Guidelines (October 19, 2005) (PDF
- 1.18 MB)
This is hard work.
Well, at least we learn what the client API looks like, on pg.10 (section
3.1). Presumably, the OIDS are used in the client API, to denote the PIV
data object, and are part of the conformance test suite.
And, then, there are the conformance tests for a bunch of wire-format PDU,
including GET/PUT, at 3.2.1. Yea! Have not seen the spec, for these, but at
least the test cases are given a mention. Presumably the test suite was
insist on the propert multi-byte encoding of the 11 registerd 2 byte tags
values
And. 3.2.2 even references the 11 named PIV datums! Ah. they were defined in
an appendix of 800-73. Must go read that.
And so, the model is possibly clear, now. GET DATA (per the validation
obligation noted in the conformance test) reference the container object,
which is essentially a value schema for the 11 datums stored in some object
manager, controled by some selected javacard applet. Could have used XML
value schema-notation, but we roll our own...presumably as applets cannot
parse/enforce XML value schemas!
Ok it _is_ easy (I think). But it really was not easy to find out how easy
it actually is!
Still would not have guessed that special semantics of 7816-4's GET/PUT
DATA were the key, here!
Presumably, the PIV card applet will implement these
semantically-specialised GET/PUT DATA commands, rather than the COS and thus
enforce the value schema rules in the Container object?
Or is the COS supposed to do this?
----
SO lets continue reading more documents: and we get to "Special Publication
800-73, Interfaces for Personal Identity Verification (April 12, 2005) (PDF
- 860 KB) " which seems really useful technically (now I have abduced the
design model):
Concerning ATRs, selects, etc, we now know that:
"The PIV Application Version is returned on response to SELECT to the PIV
Application containing the CHUID on the card, for both contact and
contactless modes.
The last byte of the application name returned indicates the Application
version in the card and the card type of Virtual Machine (VM) or File System
(FS)."
So whats this? VM is referring to a Container object-based cardedge, via
GET/PUTs, vs a FS cardedge (using READ/WRITE) on PKCS#15, perhaps?
Then there is discussion of, at the clientAPI :
gscBsiGcReadTagList()
gscBsiGcReadValue()
Is this Container object thing, related to the DoD CAC "GC" applet - in new
terminology? What is a "card type"?
Then we learn:
"The PIV application supports a dual VM and File System card edge to assure
interoperability and
maintain compatibility with existing GSC-IS based systems"
So, Im guessing its mandatory to do both GET/PUT-based applets (for
comaptibility with CAC architecture, and the BSI model) and Filesystem-based
applets ?
And then there is the ATR issue, which is linked to the CHUID issue, which
is linked to the select, whose return value implies VM card type or FS card
type (still no better off, understandwise). but clearly, its important to
address the select, post ATR, to learn the "card type".
"The PIV Application also requires a contactless interface. The contactless
command interface is
compliant with NISTIR 6887 Appendix G. However, in both cases (Virtual
Machine and File System),
the contactless interface relies on the data model Object IDs and Tags
defined in this 800-73 specification rather than the Object IDs and Tags
defined in Appendix G. Dual interface VM cards shall have the CHUID Object
available for selection in the default selected applet allowing them to
honor a Select Object/EF CHUID issued immediately after the card answer to
reset."
Ok, so ATR, Chuids, and select EF are (possibly) linked up, somehow, but the
EF option is only reelvant to dual-interraces SIMs. Hmm. Are we saying that
the CHUID value (one of the 11 datums which are PIV data, can be read using
READ BUFFER, on an EF?
Peter, getting confused again. FIPS 201/PIV == GET/PUT, not ISO FS (cite
Scott); and has nothing to do with identifying cards via ATR (cite Scott).
But then, for dual card interfaces, all that come back into play, how the
implied select should be issued (by the COS? or the host?) , post ATR?
But then, it clearly says "Note: PIV Cards must support either the VM Card
edge or the FS card edge. A mix and match of APDUs between card edges is not
allowed."
So a "PIV card", with perhaps multiple applets in its PIV application
domain, cannot (1) be a VM cardedge for one applet (2) the FS scheme for
another applet. But what about for non PIV appliiation domain applets, on
the "PIV Card"? Are they bound by this rule (being on the "PIV Card"?)
Perhaps this rule is just badly written, forgetting their may be non gov
applciation domains, on the "PIV card", in non-govt controlled silos?
Interesting, the card edge for VM doesn't mention GET/PUT. does have a GET
BUFFER 2.3.3.1.3 in some other doc. (But Im getting too tired of this... its
Soooo hard to follow the model, from the actual text provided!)
Table 15. PIV Card Application Card Commands has the GET/PUT (yea!),
concerning the "Application Card Commands" - which is now clearly different
to the VM or FS card _type_, discussed earlier. Hmm. Obivously, I dont
understand the difference, here - card commands, vs card edges, vs card
types
We do note that there is no command chaining allowed, tho, for PUT/GET, even
over T1.
Ok. perhaps its becoming clearer, remembering the PACS requirment, showin
C.1.2
In PACS mode, an contacless reader just wants to read the damn CHUID (a
serial number, for use against the HID-style card access control system),
and probaly cannot handle the signature bytes (used in more advanced
PC-based authentication processes). Does this motivate the strange
constructed encoding non-compalicne!!?
OK I think Im getting it. Its all a legacy hack, mixing BSI GC, with ISO FS,
with a legacy HID reader mode for card access control.
Still never got to the relationship of PIV data, the enorcement of ACL (by
the COS, by the container objkect handling?) , and the relationship with EF
ACLs! Wonder what document that is all specified in.
No wonder, I didnt really understand the NIST management report on PIV, that
I cited originally!
Peter.
.
From: "Scott Guthery" <[EMAIL PROTECTED]>
Reply-To: MUSCLE <[email protected]>
To: "MUSCLE" <[email protected]>, <[email protected]>
Subject: RE: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
Date: Wed, 22 Mar 2006 20:37:41 -0500
No "discovery application". No ATR. No mapping. No "interface discovery
ids" (huh?). No renaming. No context tagging. No logical channels. No
applets. No file system. No driver hacks. >One of the defining
principles of European software design is that renaming is progress.
Consider for example that quintessential European programming language,
TTCN-3. About all one can do in this programming language is rename
things. It's a tour de force to actually get something -- anything -- to
happen. But then Europeans believe that all the world needs is a couple
more layers of well-paid, job-for-life bureaucrats and we'll all live
happily ever after.
We all know how that story comes out ... 'cept, of course, the pampered
denizens of the Sorbonne.
Cheers, Scott
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Peter Williams
Sent: Wed 3/22/2006 5:34 PM
To: [email protected]
Cc:
Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
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
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
