[37688] in Kerberos
Concealing keys (not even in NSS)
daemon@ATHENA.MIT.EDU (Rick van Rein)
Tue Sep 20 01:43:23 2016
Message-ID: <57E0CC55.2070407@openfortress.nl>
Date: Tue, 20 Sep 2016 07:42:45 +0200
From: Rick van Rein <rick@openfortress.nl>
MIME-Version: 1.0
To: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hi,
I've looked into the mechanism for configurable crypto backends and in
particular the NSS backend, which is close to PKCS #11.
What I like about PKCS #11 is that it can conceal keys from the libkrb5
library, and thereby from the application's reachable memory. This is
not how the NSS crypto backend is made, I found -- keys are imported
into NSS as (session) keys and used there. If FIPS is enforced, it will
fake its patterns by unwrapping a key that was wrapped just for that sake.
This seems to me like a missed opportunity. Am I mad to think that a
crypto backend could choose any krb5_keydata representation, and that a
pkcs11: URI [RFC7512] would be fine? It looks like the surrounding
libkrb5 treats the keys as literals and always invoke krb5_k_decrypt()
and _encrypt() after expanding the key to an opaque krb5_key after
krb5_k_create_key() and before krb5_k_free_key(), right?
This does seem to be possible -- but how do others feel about this?
Cheers,
-Rick
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
