|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
RE: [Muscle] NIST Services
From: Scott Guthery (sguthery
mobile-mind.com)
Date: Sun Apr 10 2005 - 12:19:23 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello, Peter:
1) GSC-ISv2.1 has been entered into the ISO/SC17 standards process. It is in TG9 of WG4, chaired by Teresa Schwarzhoff, one of the authors of GSC-ISv2.1 and an employee of NIST. The emerging standard is called ISO/IEC 24727. There are 5 parts in various stages of drafting. Part 1=Architectur, Part 2= Generic Card Edge, Part 3=Application Programming Interface, Part 4=End-to-End Security, and Part5=Testing. All parts are firmly founded on the ISO/IEC 7816-4,-8,-9 and -15 "toolkit".
ISO/IEC 24727 is an interworking framework for interoperabilty a la the Internet. I.e. it is a way for card systems to interwork just as the Internet protocols are a way for networks to interwork. Internet. Get it?
There is a meeting of WG4 adn WG4/TF9 next week in Munich. See you there?
2) I don't know if NSA is funding any contractors to work on standards but NIST certainly is.
3) You might also like to check-out NIST Special Publication 800-73
http://csrc.nist.gov/publications/nistpubs/index.html
This is a specification for a card application purpose-built for Personal Identity Verification (PIV). The specification defines both a card edge interface and an application programming interface. The design rule was maximal KISS (Keep It Simple, Stupid) to maximise the probability of interoperability defined as "independent implementations interchangeable"
Plans for entering SP 800-73 into one or more standards processes are still up in the air.
Don't hesitate to ask follow-on questions (anybody).
Hope all is well.
Cheers, Scott
-----Original Message-----
From: muscle-bounceslists.musclecard.com on behalf of Peter Williams
Sent: Sun 4/10/2005 12:23 PM
To: 'MUSCLE'
Cc:
Subject: RE: [Muscle] NIST Services
Ok. So lets get political! Given someone mentioned ISO, and the contribution
of an NSA work product to an international forum.
So 20 years too late, ISO might specify an enumeration process for
serial-interfaced microprocessors, on 9600 bps serial buses, using
char-level link protocol. We've had ISA parallel enumeration, PCI parallel
enumeration, USB and IEEE (secure) enumeration of 400mbps serial devices,
and even SIP-based enumeration of smartcards over virtual desktop links. And
now ISO will let us ping an applet, at 9600 bps, to learn what capabilities
it has, and what stack profile it requires the host to adopt in its layer
entities, for a pseudo 7 layer stack (with 2 subprotocols for vendor
inconsistencies, per layer).
ISO is clearly on the ball! Is NSA funding a Booz Allen or a CSC contractor
in the ISO WGs? You can tell the agencies international policy goals by
their choice of the defense contractor; it's a style issue. If you look at
the individual's previous projects and area of technical excellence, you can
tell why there were picked, and therefore what the US "unstated" policy
objectives are, too.
I don't know who wrote GSC-IS, that would well form the basis of an ISO
normative standard effort. But having read the musclecard code, and only
then read the NIST document, the similarities were striking: its as if the
spec abstracted the plugins precisely, and gave everything names and
acronyms, then factored in the learning from the CAC world, and finally
tuned everything for a FIPS 140-2 ways of describing the management roles
for the parties interacting with crypto modules.
What was refreshing was that it described cryptocard KMI generically,
independent of PKI concepts. US global policy comment aside, its an
impressive technical document: it show real class. I think NIST should be
very proud of its technical content, and the effectiveness of the
presentation of the concepts. They are classical NIST skills.
What GSC-IS reading did give me in a way that was not readily apparent in
the code was (a) a clear _perspective_ on the designers goals for
characterizing the two classes of card - javacard/.NET cards, and DF/EF
cards, and (b) the role-based personalization/post-personalization
management model - that leveraged NSA expertise in centralized key
management for known-effective crypto-based network control systems.
The main problem with GSC-IS is that it's a product of the 2001 period. Its
only uses (and is conceptually limited to) C-MAC/C-ENC for SCP01, and the
base concept limits GP secure messaging in the role of remote code
distribution and simple secure personalization - not end-end messaging for
application usage. This is particularly apparent in the discussion of
CAC-related features, where the role-based management model shows off the
designers assumptions about how hosts and management entities SHOULD
cooperate, to maintain the online infrastructure.
Failure to address end-end secure messaging, for both application and card
management usages, is the big hangup, clearly. The 2001 infrastructure
assumptions may not scale to the open community, which is not like DoD in
its management culture.
In a US technology dominated world - which assumes the PC is to be a trusted
network relay (using TPM chipcontrol over personal crypto) and can
participate in infrastructure-wide surveillance and key escrow etc -
limiting the architecture to SCP01 assumptions is not such a big deal. But
the new India and China markets able to deploy new capital infrastructure,
folks are not going to use TPM, with its high IP cost basis, and the fear of
foreign spying and control over their critical infrastructure, etc. More
cheaply, most of the infrastructure benefits that GSC-IS address can come
from end-end secure messaging: card to card. (And NSA knows how to
technically architect this world, too! It clearly showed off its talents on
write-to-reader (vs trusted network) architecture infrastructures in the 10
year DMS/Fortezza project.)
I suspect, in conclusion, GSC-IS is a good work product to contribute to a
normative standards effort, at the international level. I would expect that
effort to have little or no impact on overcoming any _practical_
interoperability issues, however. Using policy to induce economic change -
in which consumers demand interoperability, is classical US international
policy. And that's what ISO normative standards are for, after all. As you
taught us, Peter, normative 7816 did not make any two compliant cards/hosts
talk to each other! But it did forment an industry and a multi-vendor
market!
Peter.
> In the typical configuration of PC with microprocessor-controlled card
> reader, none of these methods define either the card reader driver layer
> in the PC or the card reader itself, but for the startup phase of the
> card they do aim to closely define the PC software's internal interface
> to the card reder driver and the card reader interface to the card. That
> startup discipline is something that we have long needed in order to
> have interoperability across multiple card types.
>
> (If Scott reads this, perhaps he can add something - or indeed correct
> if I have got it wrong.)
>
> Peter T
>
> _______________________________________________
> Muscle mailing list
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]