From: JC <lov...@ya...> - 2007-03-24 09:32:05
|
I agree that a simple library on top of the TPM main spec 1.1, hiding the details of OIAP/OSAP, would be more than enough for most people. I know it is in our organization, and haven't come across anybody for whom it would not be enough. Leaving this aside, and leaving also aside the relative merit of the TSS layer, specifying it in such a way that its connection to the TPM main spec is not clearly detailed is not likely to help its adoption. Of course, everybody could use Trousers, without having to worry about whatever is underneath; but, like you implied, in order to use TSS effectively you really have to know about the TPM main spec, and therefore about what lies underneath Trousers (I am not trying to be facetious). Alas, Trousers won't work smoothly in all environments; for a number of reasons I am not at liberty to discuss, it won't on the platform I am interested in. --- Hal Finney <hal...@gm...> wrote: > I too have somewhat mixed feelings about the value > of the TSS layer vs > a more literal interface to basic TPM functionality. > Now, most of my > experience is with version 1.1 functionality, and I > know that 1.2 is > quite a bit more complex, so TSS may have more value > there. But as far > as 1.1 goes, I would agree that most functionality > would be about as > easy to access with a literal TPM-based API. > > One big value-add of TSS is taking care of the > details of the > OIAP/OSAP authorizations. TPMs have an unusual > security model for > providing the passwords and similar auth data for > keys, blobs and the > TPM owner secret. Rather than the client just > providing them to the > chip when needed, the TPM wants to set up a shared > secret with client > code and use cryptographic MAC functionality to let > the client prove > it knows the secret. Apparently the TPM designers > viewed it as > important that the communications channel between > client code and the > TPM was untrusted. They wanted to make it so that > even if an > eavesdropper were able to watch data going back and > forth to the chip, > he would not learn secrets that would let him > authorize uses of keys > and such. > > I don't particularly understand why they adopted > this threat model, or > what use cases it would apply to. One possibility is > that a client on > one computer is trying to use a TPM on another > computer, and they have > an insecure connection. But that kind of situation > is common with > other sorts of resources, and there is plenty of > technology to solve > it - setting up a TLS protected link between the two > computers, for > example. The other possibility is that the client > software does not > trust the operating system, daemons and device > drivers on its own > computer that are interfacing to the TPM, and it > wants to make sure > that even these components can't learn its secrets. > But that doesn't > make much sense because client code can never be > secure from a > malicious OS. All in all it seems like an odd threat > model, which has > unfortunately greatly complicated the task of > writing software to talk > to the TPM chip. Those of us who have had to get > code running in a > pre-boot environment where we don't have a friendly > TSS layer to > intercede know how challenging it can be. Trousers > and other TSS > layers play a very useful and important role by > hiding this complexity > from developers. > > Beyond that, the value-add of the TSS layer gets a > little sketchy. The > key registry for storing keys might be useful, but > it's not clear to > me that applications are really going to prefer that > over using their > own storage. To really be valuable it would need to > be useful across > multiple applications, which will require additional > standards effort. > Look at the design in the spec for a "roaming key" > and all these other > keys that are supposed to be stored in the registry > to create a > multi-level key hierarchy. I'm very skeptical that > anyone will ever > use all that. > > The TSS also keeps track of how many keys are in the > TPM and unloads > them as needed. But in practice few applications > need to worry about > this, they would like to just clear the TPM of keys > and then load > their own. Now this raises the problem of two > applications trying to > use the TPM at the same time, but the TSS doesn't > fully solve this > because one app could load a key and then find it > unloaded by another > app before the first has a chance to use it > (possibly the 1.2 > enhancements can deal with this). > > The identity-key functions are high level, but I'm > not sure that > embedding all this hybrid encrypt/decryption in the > TSS is a good > idea. It ties the application's hands as far as data > formats and I > suspect it will lead to interop problems down the > line. I would have > rather seen two entry points here, one for the > low-level MakeIdentity > function that would be called first, and then > CollateIdentityRequest > to assemble the data as needed for transmission to > the Privacy CA. > Then you could override the latter if you have > compatibility problems. > As it is I have a horrible feeling that client code > down the line will > provide a dummy CA key to CollateIdentityRequest, > decrypt the data > immediately upon return from the TSS, reformat as > needed and > re-encrypt for the PCA. Likewise for > ActivateIdentity, the TSS is > there trying to do AES decryption when that task > would IMO be better > handed off to the client. These are the only > functions where the TSS > tries to do symmetric encryption, yet in most cases > the application > layer is going to need its own AES functionality > anyway for general > secure communications. > > In venting these complaints I certainly do not mean > to minimize or > disparage the fine work by Kent on Trousers or that > of other TSS > implementors. They have faced and solved many > challenges in getting > this software layer to work. And it may well be that > the new > functionality in version 1.2 will provide more > substantial benefits to > developers. But as far as 1.1 goes, I do feel that a > simple library > that automated the OSAP/OIAP process and otherwise > provided a literal > translation of the TPM commands would be very > usable. And it would > mean one less spec to read! > > Hal > > > > On 3/23/07, JC <lov...@ya...> wrote: > > Thanks for your detailed, if appropriately > > despondent, feedback. Maybe after reading all the > > documentation one can do the mapping all right, > > although I believe that some of the TSS primitives > are > > not described in sufficient detail to prevent > > ambiguous mappings. > > > > My feeling after reading (not every word of) > the > > TSS spec is that it introduces a large and rather > > baroque layer on top of the TPM main spec. I guess > it > > is a recommended (prescribed?) approach to using > the > > TPM by people who know about these things - but it > is > > complicated big time. > > > > I mean, an API to work on top of the TPM main > spec > > would relatively simple to develop and use; > different > > parties could then elaborate on such an API to > develop > > as complex as necessary a security infrastructure. > Not > > everybody (maybe not many users?) will need the > full > > power and complexity of the TSS layer; I have seen > > other proposed standard APIs languish and finally > > become extinct, because of similar issues. > > > > To me, and in part because of the reasons you > > mentioned, TSS is an obstacle, not a > simplification, > > when it comes to using the services of the TPM. > But, > === message truncated === ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 |