On 03/12/2010 10:12 PM, Anders Rundgren wrote: > Why is replacing the 15 year old Netscape hack suddenly a bad idea? > > Because you cannot create a secure provisioning system without having > some kind of [by the issuer recognizably] predefined key in the token. > With such a key, the token would be able to attest generated keys, > import data > using MACs, and encrypt data as needed in both directions. > > In addition, you need "bookkeeping" support inside of the token so > that the > token can provide the issuer with evidence that the process indeed > succeeded > enrolling n keys etc etc. > > Without such support in tokens, all bets are off regarding where keys > are actually stored, making the value of having tokens suddenly drop > to zero, at least from the issuer's perspective. I agree with the above. The problem is that there is no standard for remote card provisioning, There are primitives that are standards (the Secure Channel Spec, for instance), but each card "type" has its own way of dealing with them (and many card "type" don't support remote provisioning at all). To date, even the Cryptoki group has washed its hands on provisioning and initialization of cards.
That being said, there is at least one open source system that has attempted to solve the problem for exactly one card type (based on it's own APDU's: That system is part of dogtag (http://pki.fedoraproject.org/wiki/PKI_Main_Page). It looks like the documentation for that part of the system isn't on the wiki, but there is some documentation on the client portion here http://www.redhat.com/docs/manuals/cert-system/8.0/esc/html/index.html A general browser solution would require a lot more thought. The Dogtag client solution is to trust the provisioning server (which the dogtag client reads from the token itself). The client basically works as a conduit to pipe apdu's from the backend server directly into the card. If the server is malicious, this could be an issue for the card. Dogtag protects itself by only getting the URL directly from the user or the Card (getting it from a keygen tag, for instance, would be an issue). This system means that the dogtag back end could be made to work with different tokens with only minimal changes to the Client (basically the client needs to be able to identify cards it can manage, and read the URL for that cards out of it). Getting the URL from the card also solves the problem of multiple cards of the same "type" but from different vendors managing them with different key sets. Anyway, I would certainly be happy to look at proposals that would advance the state of technology here. I've seen some scary things router vendors are doing which make getting workable client auth solutions all the more desirable. > > Since the progress in the token industry is mainly driven by the slowest > movers you can find on this planet, i.e. banks and governments, we can > safely conclude that on-line provisioning of keys will remain a marginal > activity in spite of all the hype around "Cloud Computing". Add the hand held devices, which often implement relatively old versions of standards (like SSL and HTML), and have no standard ports for supporting smart cards (and vendors who lock down those devices so third parties can't fixe these issues) and the outlook looks pretty bleak indeed.... but 2010 will be the year of the Smart Card;). bob > > -anders >
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
