Kyle Hamilton wrote: >> I don't completely get this. If we are talking about soft tokens of >> the kind implemented in Mozilla, PKI-using services rely on keys stored >> in containers using obfuscation and optional weak passwords as >> the only protection. IMO, this trust in client code is above the >> level of trust that PIN policy support requires since the former >> enables key theft.
>You cannot trust client code to do what you ask it to do. You cannot >trust client code to do what your security policy requires it to do. Although this is of course correct, it is also essentially saying that you cannot rely on anything in the client environment. I don't build on that assumption because there is evidence of progress in this space. This level of security should (at least) withstand trojans that try to modify security code. If it will survive a physical attack is another thing. Yes, there will surely be bugs but hopefully compartmentation, virtualization, and trusted root keys will make this manageable. Policy download and enforcement is in fact already a standard feature in mobile devices so I'm not alone stepping on thin ice. Enable "Remote Vipe" is such a policy. Then there are some philosophical aspects that i would like to bring to the table: If you require perfect solutions from day #1 you will most likely end-up with nothing because 1) nobody knows how to build them 2) few are prepared to pay for them. By doing the opposite, creating a "market" (demand) the time-line for a practical solution is much more likely to be reasonable assuming that the goal is achievable. No matter how smart (or dumb) I may be, I'm simply not able to specify a perfect solution, only a path to "better" solutions. Suggestions are BTW welcome! >A client can take a request from a server to generate a key on a >hardware token and perform the possibility entirely in software, and >the server has no means of knowing about it. Using <keygen>, generateCRMFRequest and CertEnroll this is undoubtedly true. That's one reason why I plot with a successor. >This is one of the largest, most annoying, and most severely damaging >aspects of client-server programming. (We've been discussing this on >the openssl lists lately -- the requirement that the client run code >that does what the server expects it to is a DRM problem, in which >modifications to the behavior of the code can disable the client >application.) Agreed. >> The "big picture" of this project is establishing a practical HW-crypto >> solution based on mobile phones with consumers/citizens as primary >> target. I'm not aware of anything similar going on elsewhere unless >> you consider EU eID projects as "practical". I don't because these >> schemes are based on an all-mighty CA while my scheme is based >> on a world of competing technlogies and issuers. >I'd love to have this world exist, but I'd also like to add the caveat >that not every issuer should be required to be audited to >financial-services grade. Agreed. The core idea is giving issuers a tool that they can use regardless the criticality of their services. It can be seen as a response to: http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg02109.html >> Unlike the existing schemes, KeyGen2 supports inside-of-container- >> generation-attestation which I consider a valid requirement, otherwise >> HW-crypto is a waste since the service cannot verify that a key really is >> in HW. >How is this attestation made? >(I'm asking because I cannot find your KeyGen2 submission, since you >withdrew it "[d]ue to IPR issues".) Such a mechanism has been defined by TrustedComputingGroup. I have proposed a simpler variant but the principle is the same: http://webpki.org/papers/keygen2/SubjectKeyAttestationEvidence-light__InventionDisclosure.pdf >If you're working with TPMs and relying on configuration registers, >they can be emulated. Everything can be emulated, really, and you're >still relying on the client computer to do what the server expects. This part is about trusted client code and is independent on key attestations which cannot be emulated since they derive trust from a HW-protected key that neither can be emulated nor forced to do something is wasn't programmed for (i.e. a smart card). >> If you look closely on <keygen>, generatecRMFRequest and CertEnroll, >> certificate request is redundant (is thrown away by the CA), it is really a >> key generation response you need and is implemented in KeyGen2. >Not everything in a CSR is thrown away. Not everything in a CSR needs >to be thrown away. Perhaps it does for financial-services CAs, but >not for all CAs. AFAIK a CSR is typically a signed object that as a minimum contains the public key of the generated key-pair. A CA usually only needs the public key since the cert data is already known anyway for browser-based provisionings unless you work in a session-less mode. KeyGen2 can also work in a session-less mode but it doesn't do that through clobbering the CSR because some of the data may not have anything to do with what you plan to have in the certificate. KeyGen2's solution is called ServerCookie and is a universal way of including round-trip data. <snip> Anders _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
