thanks a lot, now that you explain it again that clearly, I can see the
difference. Somehow, I had in mind that those "crypting-objects" are
wire-hard-coded, that the soft-toks just emulates some hardware, and
that you just could forward your requests to that hard-coded logic, and
get some answer. I didn't see that those algorithms could also be
instances/objects that do something, that you could use like instances
in the application code itself. I think I didn't figure that the tokens
themselves are oop-things. But that's great.
The tpm I use, as long as I know, as no crypto-instances or almost none.
Or calls to them aren't implemented in TrouSerS. That's something I read
when I installed opencryptoki and the tpm-kernelmodule.
I'll have to look at SDR again. Since I don't exactly understand how the
soft-token in NSS is implemented, I hope SDR doesn't make calls to that
token to encrypt, like if it was a crypto-device like you just
explained. It's true that I haven't been deep enough to find the DES
altorithm itself, in SDR. I hope it's somewhere in a library, not inside
a token. Otherwise, if I take the key from another token, but use the
soft-tok to encrypt, that's like if I used 2 different tokens and mixed
up the key from one with the functions of the other. Would not be a
great thing...
thanks!
Nelson B Bolyard schrieb:
On 2009-11-24 13:00 PST, Marc Kaeser wrote:
Are there unpersistant keys in a token? I'll also look for that point in
the specs.
Yes, in the PKCS#11 model, *ALL* objects (key objects, cert objects, etc.)
live in tokens. All crypto engines live in tokens, too, at least conceptually.
Some objects are persistent, and continue to live (albeit in a state of
suspended animation) when the token is removed from the slot, or is powered
off, or the process that is using them exits, or the process destroys the
"session" in which the object was created. Those objects are called "token
objects" (an endless source of confusion).
Other objects are temporary. They live in tokens, just like "token objects"
but, unlike "token objects", if the token is removed, or the process that
created them ends, or the process that created them destroys the session
in which they were created, then they vanish, forever, poof, gone. They
are called "session objects" because their lifetime never exceeds the
lifetime of the session in which they were created.
"Session objects" that are keys are called "session keys". "Token objects"
that are keys are called "token keys". Similar conventions apply for certs
and other types of objects.
Again, all "session objects" and "token objects" live in tokens. All the
PKCS#11 crypto engines exist (at least conceptually) in tokens. When you
invoke any of the C_functions to do a crypto operations, you're asking a
token to do something with a crypto engine on that token, typically using
a key on that token (a "session key" or a "token key").
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
