On 12/07/2009 12:13 PM, Marc Kaeser wrote: > Hello Bob > > > Robert Relyea schrieb: >> On 11/28/2009 11:49 PM, Marc Kaeser wrote: >>> Dear NSS gurus, what do you think, would it really be a bad idea to >>> use the key from another token, but still use the internal token to >>> encrypt? When SDR is called, I could check if the token I want to use >>> also provides the encryption mechanism I need. If it doesn't, I could >>> use the internal token, which should always be present anyway. So I >>> could be able to save the key wherever I want, even if the token >>> doesn't provide the algorithms I need. I don't know if it is legal in >>> the view of NSS or PKCS11 to use 2 Tokens for the same operation. >> NSS supports this. They higher level calls (create context, encrypt, >> finialize context) moves keys around automatically. This only works, >> however, if both of the following is true: >> 1) the source token doesn't support key extraction -- or -- the >> target token doesn't support key injection (Softoken in FIPS mode, for >> instance). >> - and - >> 2) there isn't a key exchange method (like RSA) that can be >> used to move the keys. >> >> I find it weird that the TPM has a des key, but can't do des operations. >> I would be particularly surprised if that des key was extractable (can >> be copied out of the token). That seems to be a potential security issue >> to me. > > The TPM itself is stupid, it can't do many things. Most of the time, > it is used to securely store keys. You want to securely save (encrypt) > a symetric key? No prob: create an asymetric key from which the > private part stays in the TPM, and use the public part to encrypt the > symetric key you want to use to encrypt your things. > > The TPM has a so called endorsement key, which never ever leaves the > TPM. It's the top of the daisy-chain of keys within a TPM. This > endorsement key is used to create the SRK, Storage Root Key. The SRK > ist crypted by the public part of the Endorsement Key. You can create > exportable or non exportable SRKs. Then you can create symetric keys, > which you encrypt with the public part of the SRK. (so if the SRK was > exportable, you can export the keys. Otherwise not) You can bind > (exportable) or seal (not exportable) data to your hardware, if you > encrypt that data with a symetric key which is encrypted by the public > part of e.g. the SRK. > > On top of that, PKCS11 is just implemented in either openCryptoki > and/or IBM TrouSerS, using the TPM in the "background". > > At this point, I think you can't just save a key protected by the tpm > with PKCS11. I don't know the implementation enough to tell. But you > may be able to generate one, using the daisy-chains of the TPM to > create a secure symetric key. > > I also have to test if by chance opencryptoki/tss support 3DES > encryption.
OK, well it will still work to have a key in a token and do the operation elsewhere. PK11_CreateContextBySymKey will automatically try to move the key into a token that can to do the requested operation. It will fail if the key can't be extracted or key exchanged into the new token (which is most likely in FIPS mode... it would be good to test that). > > > >>> I guess I can't just change the mechanism and use another one, I don't >>> see all the dependencies, but maybe there would be an overflow >>> somewhere, if the cyphered text exeeds a given length, if I use >>> another symetric encryption algorithm. >>> >>> What do you think? >> >> Oh, the key isn't a des key, that make more sense to me. > > > Which key do you mean at this point? Isn't the key of the internal > token a key used to encrypt using triple DES Mechanism? I was assuming that you wanted to use another mechanism because your token supports another mechanism. It turns out this is doable if you need it. > > > I'd have to >> check, but I thought the algorithm was carried in the SDR package (DER >> encoded). If it's not, that is an oversight which will certainly cause >> some problems here. >> >> bob > > Yes, I think the encryption algo is in the SoftTok. "C_EncryptUpdate" > is called. > http://mxr.mozilla.org/mozilla1.9.1/source/security/nss/lib/pk11wrap/pk11cxt.c#670 > > > not cool... No, that value is set externally by some C_EncryptInit call. The question is did the SDR code pick the PKCS #11 mechanism itself, or did it read it from the DER encoded data. OK, I've just looked at the code. It does encode the encryption type in DER. At line 200 it sets it to CKM_DES3_CBC, then at line 252 it creates the ASN1 algorithm ID for SEC_OID_DES3_CBC. There are two separate numbers here: the CKM_ number is the PKCS #11 mechanism. The SEC_OID_ number is the NSS int representation for the oid value (used in ASN.1 encoding). There are two functions that convert from one to another: PK11_AlgtagToMechanism converts a SEC_OID_ number to a CKM_ number. PK11_MechanismToAlgtag converts a CKM_ number to a SEC_OID number. Anyway it should be a relatively easy to pick an appropriate mechanism for a given token (PK11_DoesMechanism() will tell you if a given mechanism is supported by a token), or based on a key ( PK11_GetKeyMechanism() will help here, though you should make sure you get an encryption and not a MACing or Signing mechanism), then select the appropriate algtag/OID value from that. No changes are needed for Decrypt (for this). It will automatically get the correct Mechanism from the Der wrapped package. > > How about "extracting" the algo from the softtok, and put it into sdr? > Where in the source is it coded? No need, the code knows because it told softoken what mechanism to use. > > Marc
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
