[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: [dev-crypto] Interoperability between java.security.Key and org.bouncycastle.crypto.engines?
From:       Maarten Bodewes <maarten.bodewes () gmail ! com>
Date:       2011-09-19 22:47:46
Message-ID: CADwHJ+82DWQ7fAX=8N9wCs9AF7x2HDnAvFWY0Ya_wLPXpZ8qnw () mail ! gmail ! com
[Download RAW message or body]

I already wrote a reply, but I cannot find it in my Gmail for some reason.

You don't understand the way the Java crypto API or BC works:

Application level: BC: CMS and PGP application *protocols*
Interface: Java JCA
Implementation: E.g. Bouncy Castle software provider or Sun PKCS#11 Provider
Lower level implementation: Bouncy Castle API or PKCS#11 module
implementing the *algorithms*

For info about providers:

http://download.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html


It would be possible to create a Mac implementation in your own
provider that uses a PKCS#11 cipher instead of a direct PKCS#11 MAC
for some algorithms. This wont work for HMAC since it requires the key
material as input for the hashing.

Regards,
Maarten

On Mon, Sep 19, 2011 at 23:14, Alex Savitsky
<alex.savitsky@securekey.com> wrote:
> I seem to be missing something here... Sun JCE isn't a hardware crypto provider, \
> either, but the interfaces it provides allow working with the Key instances, \
> without needing the underlying key representation: 
> javax.crypto.Mac mac = javax.crypto.Mac.getInstance("HmacSHA256");
> mac.init(key); // getEncoded is never called directly, JCE somehow manages to use \
> it behind the scenes 
> but the classes provided by BC don't allow that kind of initialization, insisting \
> on byte[] instead: 
> org.bouncycastle.crypto.macs.HMac hmac = new org.bouncycastle.crypto.macs.HMac(new \
> SHA256Digest()); hmac.init(new KeyParameter(key.getEncoded())); // explicitly \
> require byte array key representation, there's no way to initialize with just the \
> Key instance 
> If this is not the case of a simple omission, but rather a global limitation, we'd \
> like to know that, as our projects heavily use HSMs, and we'd like to stick to the \
> HSM-neutral interfaces (java.security., that is) as much as possible. 
> Thanks,
> 
> Alex Savitsky
> 
> -----Original Message-----
> From: Maarten Bodewes [mailto:maarten.bodewes@gmail.com]
> Sent: Monday, September 19, 2011 3:39 PM
> To: dev-crypto@bouncycastle.org
> Subject: Re: [dev-crypto] Interoperability between java.security.Key and \
> org.bouncycastle.crypto.engines? 
> On Mon, Sep 19, 2011 at 19:29, Alex Savitsky
> <alex.savitsky@securekey.com> wrote:
> > All crypto engines in org.bouncycastle.crypto.macs (or at least the ones
> > derived from BlockCipher) are seem to be taking cryptographic key parameters
> > only in the form of byte[] (or, rather, in the form of
> > org.bouncycastle.crypto.params.KeyParameter which takes byte[] arguments).
> > However, there are some keys which don’t expose their byte array content
> > (HSM keys coming from PKCS11 keystores, for example), and therefore cannot
> > be used to construct KeyParameter instances. Is there a way to initialize
> > the BC crypto engines off such keys, and if not, is this feature planned to
> > be implemented?
> 
> BC is a software cryptography provider, and therefore it cannot access
> the information of the keys as it is protected by the HSM.
> 
> There are two ways around that:
> 1) use a PKCS#11 provider by Sun, IAIK or the provider of the HSM to
> obtain the required functionality in the HSM itself.
> 2) directly use the low level PKCS#11 IAIK libraries to obtain the
> data for the keys (*if* it is available to the user of course).
> 
> Regards,
> Maarten
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]