iaik.cms.SecurityProvider
iaik.cms.IaikProvider
|
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||||||
java.lang.Object
public class IaikProvider
This class implements a CMS SecurityProvider for the IAIK-JCE cryptographic provider "IAIK".
SecurityProvider| Field Summary | |
|---|---|
static java.lang.String |
ALG_SIGNATURE_RAWRSA
Constant string RawRSA. |
static java.lang.String |
ALG_SIGNATURE_RAWRSASSA_PKCS1_V15
Constant string RawRSASSA-PKCS1-v1_5. |
| Constructor Summary | |
|---|---|
IaikProvider()
Default Constructor. |
|
IaikProvider(boolean installProvider)
Creates an IaikProvider. |
|
| Method Summary | |
|---|---|
byte[] |
calculateSignatureFromHash(AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
java.security.PrivateKey privateKey,
byte[] digest)
Calculates the signature value for a CMS SignerInfo over the given digest value with the given algorithm using the supplied private key. |
byte[] |
calculateSignatureFromSignedAttributes(AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
java.security.PrivateKey privateKey,
byte[] signedAttributes)
Calculates the signature value for a CMS SignerInfo over the given signed attributes with the given algorithm using the supplied private key. |
void |
checkDomainParameters(java.security.PrivateKey myKey,
java.security.PublicKey otherKey)
Checks if the given private and public key agreement keys have the same domain parameters. |
javax.crypto.SecretKey |
createSharedKeyEncryptionKey(AlgorithmID keyAgreeAlg,
java.security.PrivateKey myKey,
java.security.PublicKey otherKey,
AlgorithmID kea,
int kekLength,
byte[] ukm,
java.lang.String kekName)
Create a shared secret key encryption key for the given key agree algorithm. |
javax.crypto.SecretKey |
decryptKey(byte[] encryptedKey,
AlgorithmID kea,
java.security.PrivateKey recipientKey,
java.lang.String cekAlgorithmName)
Decrypts the given encrypted content encryption key for a KeyTransRecipientInfo. |
java.security.Key |
deriveKey(char[] password,
AlgorithmID keyDerivationAlg,
java.security.spec.AlgorithmParameterSpec paramSpec)
Uses the requested key derivation function to create a secret key from the supplied password. |
java.security.spec.AlgorithmParameterSpec |
generateAEADParamSpec(AlgorithmID contentAuthEncAlg,
byte[] encodedAuthAttributes,
byte[] mac,
long inputLength)
Generates an AlgorithmParameterSpec for the given content-authenticated encryption algorithm. |
java.security.spec.AlgorithmParameterSpec |
generateAEADParamSpec(AlgorithmID contentAuthEncAlg,
byte[] encodedAuthAttributes,
long inputLength)
Generates an AlgorithmParameterSpec for the given content-authenticated encryption algorithm. |
javax.crypto.SecretKey |
generateKey(AlgorithmID algorithm,
int keyLength)
Generates a SecretKey for the requested algorithm. |
java.security.KeyPair |
generateKeyAgreementKeyPair(AlgorithmID keyAgreeAlgorithm,
java.security.PublicKey otherKey)
Generates a key pair with same domain parameters as the given public key for the given key agreement method. |
java.security.spec.AlgorithmParameterSpec |
getAlgorithmParameterSpec(AlgorithmID algID)
Gets algorithm parameter specification from the given AlgorithmID. |
ASN1Object |
getASN1OriginatorPublicKey(java.security.PublicKey originatorPublicKey)
Gets an ASN.1 representation of the provided originator public key. |
java.security.Key |
getPBEKey(char[] password,
AlgorithmID pbeAlg)
Creates secret key from the supplied password using the specified PBE algorithm. |
java.security.SecureRandom |
getSecureRandom()
Returns an instance of the default SecureRandom class set in iaik.security.random.SecRandom. |
void |
setAEADMac(java.security.spec.AlgorithmParameterSpec paramSpec,
byte[] mac)
Sets the mac value for the given AEAD AlgorithmParameterSpec. |
java.security.spec.AlgorithmParameterSpec |
setIv(java.security.AlgorithmParameters params,
byte[] iv)
Creates an AlgorithmParameterSpec containing any parameters from the given AlgorithmParameters object and the given iv. |
static void |
turnOffIAIKProviderVersionCheck()
If the IAIK crypto provider is used but its version is not appropriate for this version of IAIK-CMS, an warning message is printed to System.out to use a more recent version of IAIK-JCE. |
javax.crypto.SecretKey |
unwrapKey(byte[] wrappedCek,
AlgorithmID kea,
java.security.Key kek,
java.security.AlgorithmParameters params,
java.lang.String cekAlgName)
Unwraps the given wrapped (encrypted) secret content encryption key for a KEKRecipientInfo or KeyAgreeRecipientInfo. |
boolean |
verifySignatureFromHash(AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
java.security.PublicKey publicKey,
byte[] digest,
byte[] signatureValue)
Verifies the signature value of a CMS SignerInfo object with the given algorithm using the supplied public key. |
boolean |
verifySignatureFromSignedAttributes(AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
java.security.PublicKey publicKey,
byte[] signedAttributes,
byte[] signatureValue)
Verifies the signature value of a CMS SignerInfo calculated over the given signed attributes with the given algorithm using the supplied public key. |
byte[] |
wrapKey(javax.crypto.SecretKey cek,
AlgorithmID kea,
java.security.Key kek,
java.security.AlgorithmParameters params)
Wraps the given secret content encryption key for a KEKRecipientInfo or KeyAgreeRecipientInfo, or PasswordRecipientInfo. |
| Methods inherited from class java.lang.Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Field Detail |
|---|
public static final java.lang.String ALG_SIGNATURE_RAWRSA
RawRSA. Used by this provider with getSignature().
public static final java.lang.String ALG_SIGNATURE_RAWRSASSA_PKCS1_V15
RawRSASSA-PKCS1-v1_5. Used by this provider with getSignature().
| Constructor Detail |
|---|
public IaikProvider()
public IaikProvider(boolean installProvider)
installProvider - whether to install the IAIK provider within
the JCA framework or to use it without
installing it within the JCA framework| Method Detail |
|---|
public byte[] calculateSignatureFromSignedAttributes(AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
java.security.PrivateKey privateKey,
byte[] signedAttributes)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
java.security.SignatureException
Each SignerInfo included in a CMS SignedData
object may calculate the signature value differently depending on the
presence of signed attributes:
SignerInfo for
calculating the signature when signed attributes are present.
When writing your own SecurityProvider and overriding
this method, be aware that only the -- yet NOT hashed -- DER encoding of
the signed attributes is supplied to this method. For that reason this
method can be overriden for use with smartcards requiring to do the
digest calculation theirselves: ensure that your SignerInfo contains signed attributes and override this method in a way
to pass the given DER encoding of the signed attributes to your smartcard
for doing the signature (and digest) calculation.
Since this method requires to calculate the digest value over the DER encoded signed attributes as part of the signature calculation, it uses a ordinary JCA Signature engine.
calculateSignatureFromSignedAttributes in class SecurityProvidersignatureAlgorithm - signatureAlgorithm the signature algorithm to be
used, e.g. rsaEncryption, DSAdigestAlgorithm - the digest algorithm to be used for hash computation (e.g.
SHA-1,..., SHA-512); may be necessary for some signature schemes (e.g.
to be included as a DigestInfo in a PKCS#1 RSA signature)privateKey - the private key of the signer (i.e. the one supplied when
creating a SignerInfo object; may be
some kind of "dummy" key when used for smartcardssignedAttributes - the DER encoding of the signed attributes over which
the signature shall be calculated
java.security.NoSuchAlgorithmException - if no Signature engine is available for the requested algorithm
java.security.InvalidKeyException - if the key is not valid
if - signature calculation fails
java.security.SignatureException
public byte[] calculateSignatureFromHash(AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
java.security.PrivateKey privateKey,
byte[] digest)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
java.security.SignatureException
Each SignerInfo included in a CMS SignedData
object may calculate the signature value differently depending on the
presence of signed attributes:
SignerInfo for
calculating the signature when no signed attributes are present. Since
the data to be signed may be of arbitrary size this method expects the
already hashed data to only calculate the signature value on it (for
instance, by doing the digest encrypting when using RSA for signing).
For that reason, when writing your own SecurityProvider and overriding this method, you will need some kind of RAW signature (respectively digest encryption) mechanism only expecting the already hashed data (e.g. a "RawDSA" signature engine when using DSA repectively a Cipher engine when using RSA).
If you want to override this method for use with smartcards, please be sure
that your smartcard is able to do the signature (respectively digest
encryption) operation only. However, if your smartcard requires to supply
the whole data for doing the hash calcualtion itself, you may ensure that
your SignerInfo contains signed attributes
and override method calculateSignatureFromSignedAttributes for calculating the signature over
the DER encoding of the signed attributes (thereby doing the hash
computation, too).
calculateSignatureFromHash in class SecurityProvidersignatureAlgorithm - signatureAlgorithm the signature algorithm to be
used, e.g. rsaEncryption, DSAdigestAlgorithm - the digest algorithm used for hash computation (e.g.
SHA-1, ..., SHA-512); may be necessary for some signature schemes (e.g.
to be included as a DigestInfo in a PKCS#1 RSA signature)privateKey - the private key of the signer (i.e. the one supplied when
creating a SignerInfo object; may be
some kind of "dummy" key when used for smartcardsdigest - the digest value over which the signature shall be calculated
java.security.NoSuchAlgorithmException - if any of the required algorithms is not supported
java.security.InvalidKeyException - if the key is not valid
java.security.SignatureException - if signature calculation fails
public boolean verifySignatureFromSignedAttributes(AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
java.security.PublicKey publicKey,
byte[] signedAttributes,
byte[] signatureValue)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
java.security.SignatureException
Each SignerInfo included in a CMS SignedData
object may calculate the signature value differently depending on the
presence of signed attributes:
SignerInfo for
verifying the signature when no signed attributes are present.
When writing your own SecurityProvider and overriding this method, be aware
that only the -- yet NOT hashed -- DER encoding of the signed attributes is
supplied to this method. Although generally for public key operations
smartcards may not be used, this method can be overriden for use
with smartcards requiring to do the digest calculation theirselves: ensure that
your SignerInfo contains signed attributes and
override this method in a way to pass the given DER encoding of the signed
attributes to your smartcard for doing the signature verification (including
any digest calculation required).
Since this method requires to calculate the digest value over the DER encoded signed attributes as part of the signature verification, it uses a oridinary JCA Signature engine.
verifySignatureFromSignedAttributes in class SecurityProvidersignatureAlgorithm - signatureAlgorithm the signature algorithm to be
used, e.g. rsaEncryption, DSAdigestAlgorithm - the digest algorithm to be used for hash computation (e.g.
SHA-1, ..., SHA-512);publicKey - the public key of the signersignedAttributes - the DER encoding of the signed attributes over which
the signature has been calculatedsignatureValue - the signatureValue the signature value to be verified
true if the signature is ok, false if not
java.security.NoSuchAlgorithmException - if any of the required algorithms is not supported
java.security.InvalidKeyException - if the key is not valid
java.security.SignatureException - if signature verification fails because of some computation error
public boolean verifySignatureFromHash(AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
java.security.PublicKey publicKey,
byte[] digest,
byte[] signatureValue)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
java.security.SignatureException
Each SignerInfo included in a CMS SignedData
object may calculate the signature value differently depending on the
presence of signed attributes:
SignerInfo for
verifying the signature when no signed attributes are present. Since
the data to be verified may be of arbitrary size this method expects the
already hashed data to only be verified against the signature value.
For that reason, when writing your own SecurityProvider and overriding this method, you will need some kind of RAW signature (respectively "encrypted digest decryption") mechanism only expecting the already hashed data (e.g. a "RawDSA" signature engine when using DSA or "RawRSA" signature engine when using RSA).
Although generally for public key operations smartcards may not be used,
when overriding this method for use with smartcards, please be sure
that your smartcard is able to do the signature verification operation only.
However, if your smartcard requires to supply the whole data for doing the
hash calcualtion itself, you may ensure that your SignerInfo contains signed attributes and override method verifySignatureFromSignedAttributes
for verifying the signature calculated from the DER encoding of the signed
attributes (thereby doing the hash computation, too).
verifySignatureFromHash in class SecurityProvidersignatureAlgorithm - signatureAlgorithm the signature algorithm to be
used for verification, e.g. rsaEncryption, DSAdigestAlgorithm - the digest algorithm that has been used for hash
computation (e.g. SHA-1, ..., SHA-512); may be necessary for some signature
schemes (e.g. to be check against a DigestInfo in a PKCS#1 RSA signature)publicKey - the public key of the signerdigest - the digest value to be verified
true if the signature is ok, false if not
java.security.NoSuchAlgorithmException - if any of the required algorithms is not supported
java.security.InvalidKeyException - if the key is not valid
java.security.SignatureException - if signature verification fails because
of some crypto related or parsing error
public javax.crypto.SecretKey decryptKey(byte[] encryptedKey,
AlgorithmID kea,
java.security.PrivateKey recipientKey,
java.lang.String cekAlgorithmName)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
javax.crypto.NoSuchPaddingException,
javax.crypto.BadPaddingException
KeyTransRecipientInfo.
CMS EnvelopedData uses the KeyTransRecipientInfo type for
encrypting the secret content encryption key with the public key of
the recipient. Currently in general RSA PKCS#1v1.5 is used for key
transport. If rsaEncryption is requested as key encryption algorithm
this method uses a RSA Cipher ("RSA/ECB/PKCS1Padding/Encrypt") for
decrypting the encrypted content encryption key with the supplied
private key of the recipient. If another algorithm than RSA is requested,
this method throws a NoSuchAlgorithmException. An application wishing to
support another algorithm may override this method.
decryptKey in class SecurityProviderencryptedKey - the encrypted content encryption key to be decryptedkea - the key encryption alglorithm to be used, e.g. rsaEncryptionrecipientKey - the private key of the recipient to be used for decrypting
the encrypted content encryption keycekAlgorithmName - the name of the content encryption key (e.g. "AES") to be set for the
SecretKey object created by this method
java.security.NoSuchAlgorithmException - if the requested algorithm is not available
java.security.InvalidKeyException - if the decryption key is not valid
javax.crypto.NoSuchPaddingException - if the required padding scheme is not supported
javax.crypto.BadPaddingException - if an padding error occurs
public javax.crypto.SecretKey createSharedKeyEncryptionKey(AlgorithmID keyAgreeAlg,
java.security.PrivateKey myKey,
java.security.PublicKey otherKey,
AlgorithmID kea,
int kekLength,
byte[] ukm,
java.lang.String kekName)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
java.security.InvalidAlgorithmParameterException
Creating a shared key encryption key is required when a key agreement algorithm
is used as key management protocol for the recipient of an EnvelopedData or
AuthenticatedData object. The shared key encryption key will be used by an
KeyAgreeRecipientInfo to encrypt
the secret content encryption key or Mac key.
This method only works for Ephemeral and Static Static Difiie Hellman (ESDH, SSDH).
createSharedKeyEncryptionKey in class SecurityProviderkeyAgreeAlg - the key agreement algorithmmyKey - the private key agreement key of the one partyotherKey - the public key agreement key of the other partykea - the key ancryption algorithm (may be required for kek generation)kekLength - the length of the shared key encryption key to be generatedukm - any user keying material that may be required for kek generationkekName - the name of the key encryption algorithm
java.security.NoSuchAlgorithmException - if the requested algorithm is not available
java.security.InvalidKeyException - if there is a key related problem
java.security.InvalidAlgorithmParameterException - if the parameters are invalid
public void checkDomainParameters(java.security.PrivateKey myKey,
java.security.PublicKey otherKey)
throws java.security.InvalidParameterException
If the supplied keys are ESDH keys the parameters are checked.
Otherwiese super.checkDomainParameters is called.
checkDomainParameters in class SecurityProvidermyKey - the private key of the first partyotherKey - the public key of the other party
InvalidParameterEyception - if the domain parameters do not match
java.security.InvalidParameterException
public java.security.KeyPair generateKeyAgreementKeyPair(AlgorithmID keyAgreeAlgorithm,
java.security.PublicKey otherKey)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
java.security.InvalidAlgorithmParameterException
This method is called by the library for creating the originator key pair if
the OriginatorPublicKey alternative is used
for representing the public key of the originator within a KeyAgreeRecipientInfo. The public key supplied
to this method is the one of the recipient and the key pair returned by this
method must have domain parameters matching to those of the given recipient public
key. Note that ephemeral static Diffie Hellmean (ESDH) is the default key
agreement method used by the CMS types EnvelopedData and
AuthenticatedData. According RFC 5652 the
OriginatorPublicKey has to be used for representing the public
key of the originator if ESDH is used as key agreement algorithm.
generateKeyAgreementKeyPair in class SecurityProviderkeyAgreeAlgorithm - the key agreement algorithm to be usedotherKey - the public key of the other party
java.security.NoSuchAlgorithmException - if the requested algorithm is not available
java.security.InvalidKeyException - if the key is not appropriate for the key agreement algorithm
java.security.InvalidAlgorithmParameterException - if the parameters are invalid
public ASN1Object getASN1OriginatorPublicKey(java.security.PublicKey originatorPublicKey)
throws CMSException
For some key agree algorithms CMS may require a special key encoding for the KeyAgreeRecipientInfo OriginatorPublicKey choice. According to
RFC 3370 (Cryptographic Message Syntax Algorithms), ESDH public keys have to
be encoded with absent parameters in their AlgorithmID field when encoded as originator
public keys:
The originatorKey algorithm field MUST contain the dh-public-number object identifier with absent parameters. The originatorKey publicKey field MUST contain the sender's ephemeral public key.If the supplied key is an ESDH key this method returns an ASN.1 representation with absent parameters. Otherwise it simply calls super.getASN1OriginatorPublicKey.
getASN1OriginatorPublicKey in class SecurityProvideroriginatorPublicKey - the originator public key from which to get an ASN.1 representation
CMSException - if the key cannot be ASN.1 represented
public java.security.spec.AlgorithmParameterSpec getAlgorithmParameterSpec(AlgorithmID algID)
throws java.security.spec.InvalidParameterSpecException
getAlgorithmParameterSpec in class SecurityProvideralgID - the AlgorithmID from which to get the parameter specification
null
for any other algorithm
java.security.InvalidParameterException - if an error occurs when trying to fetch the algorithm parameter
specification
java.security.spec.InvalidParameterSpecException
public java.security.Key getPBEKey(char[] password,
AlgorithmID pbeAlg)
throws java.security.NoSuchAlgorithmException,
java.security.spec.InvalidKeySpecException
getPBEKey in class SecurityProviderpassword - the password for creating the secret keypbeAlg - the PBE algorithm to be used
java.security.NoSuchAlgorithmException - if the requested algorithm is not available
java.security.spec.InvalidKeySpecException - if the key cannot be created from the password specification
public java.security.Key deriveKey(char[] password,
AlgorithmID keyDerivationAlg,
java.security.spec.AlgorithmParameterSpec paramSpec)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidAlgorithmParameterException
deriveKey method of the super
SecurityProvider class is called.
If PBKDF2 is used, the parameters may be suppled as IAIK-JCE
iaik.security.spec.PBEKeyAndParameterSpec (password,
salt, iteration count, derived key length) or as
javax.crypto.spec.PBEParameterSpec (salt, iteration count).
If the parameters are given as PBEKeyAndParameterSpec
the application has take care to ensure that the passwords supplied
by the password parameter and in the PBEKeyAndParameterSpec
parameter are identical (i.e. this method does not look if
they are the same). If no parameters are supplied they maybe
parsed from the key derivation algorithm id.
deriveKey in class SecurityProviderpassword - the password for creating the secret keykeyDerivationAlg - the key derivation function to be usedparamSpec - any required algorithm parameters; may be null
if no parameters are required or the parameters
are supplied via the AlgorithmID; may also
contain the password in which case the
password parameter maybe null;
java.security.NoSuchAlgorithmException - if the requested key derivation function is not available
java.security.InvalidAlgorithmParameterException - if the parameters are invalid or cannot be
parsed from the algorithmID
public byte[] wrapKey(javax.crypto.SecretKey cek,
AlgorithmID kea,
java.security.Key kek,
java.security.AlgorithmParameters params)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
java.security.InvalidAlgorithmParameterException,
javax.crypto.IllegalBlockSizeException,
javax.crypto.BadPaddingException
KEKRecipientInfo or KeyAgreeRecipientInfo, or PasswordRecipientInfo.
This method only is implemented for wrapping a content encryption key with the PWRI-KEK ("1.2.840.113549.1.9.16.3.9") algorithm presented in RFC 3211 (Password-based Encryption for CMS), section 2.3.1:
The key wrap algorithm is performed in two phases, a first phase which
formats the CEK into a form suitable for encryption by the KEK, and a
second phase which wraps the formatted CEK using the KEK.
Key formatting: Create a formatted CEK block consisting of the
following:
1. A one-byte count of the number of bytes in the CEK.
2. A check value containing the bitwise complement of the first
three bytes of the CEK.
3. The CEK.
4. Enough random padding data to make the CEK data block a
multiple of the KEK block length and at least two KEK cipher
blocks long (the fact that 32 bits of count+check value are
used means that even with a 40-bit CEK, the resulting data size
will always be at least two (64-bit) cipher blocks long). The
padding data does not have to be cryptographically strong,
although unpredictability helps. Note that PKCS #5 padding is
not used, since the length of the data is already known.
The formatted CEK block then looks as follows:
CEK byte count || check value || CEK || padding (if required)
Key wrapping:
1. Encrypt the padded key using the KEK.
2. Without resetting the IV (that is, using the last ciphertext
block as the IV), encrypt the encrypted padded key a second
time.
The resulting double-encrypted data is the EncryptedKey.
For any other key encryption algorithm (kea) method
wrapKey of super class SecurityProvider is called.
For PWRI-KEK this method expects that the kea algorithm ID contains the kek encryption algorithm (and any associated
parameters) to be used. Any parameters supplied by params
are ignored. The supplied kek key encryption key already
has to be the one derived from a password (if PBE is used).
Since PWRI-KEK requires the usage of initialization vectors it only may work properly with kek ciphers and modes using themselves an iv (e.g. AES in CBC mode.
wrapKey in class SecurityProvidercek - the secret content encryption key to be wrapped (encrypted)kea - the key wrap (encryption) algorithm to be used, PWRI-KEKkek - the key encryption key to be used for encrypting the content
encryption keyparams - any algorithm parameters required for initializing the
key encryption cipher; ignored for PWRI-KEK
java.security.NoSuchAlgorithmException - if the requested algorithm is not available
java.security.InvalidKeyException - if the key encryption key is not valid
java.security.InvalidAlgorithmParameterException - if the parameters cannot be parsed from
the kea algorithm id or are not valid
javax.crypto.IllegalBlockSizeException - if the cipherblock size is not correct
javax.crypto.BadPaddingException - if an padding error occurs
public javax.crypto.SecretKey unwrapKey(byte[] wrappedCek,
AlgorithmID kea,
java.security.Key kek,
java.security.AlgorithmParameters params,
java.lang.String cekAlgName)
throws java.security.NoSuchAlgorithmException,
java.security.InvalidKeyException,
java.security.InvalidAlgorithmParameterException
KEKRecipientInfo or KeyAgreeRecipientInfo.
This method only is implemented for unwrapping an encrypted content encryption key with the PWRI-KEK ("1.2.840.113549.1.9.16.3.9") algorithm presented in RFC 3211 (Password-based Encryption for CMS), section 2.3.2:
2.3.2 Key Unwrap
Key unwrapping:
1. Using the n-1'th ciphertext block as the IV, decrypt the n'th
ciphertext block.
2. Using the decrypted n'th ciphertext block as the IV, decrypt
the 1st ... n-1'th ciphertext blocks. This strips the outer
layer of encryption.
3. Decrypt the inner layer of encryption using the KEK.
Key format verification:
1a. If the CEK byte count is less than the minimum allowed key
size (usually 5 bytes for 40-bit keys) or greater than the
wrapped CEK length or not valid for the CEK algorithm (eg not
16 or 24 bytes for triple DES), the KEK was invalid.
1b. If the bitwise complement of the key check value doesn't match
the first three bytes of the key, the KEK was invalid.
For any other key encryption algorithm (kea) method
unwrapKey of super class SecurityProvider is called.
For PWRI-KEK this method expects that the kea algorithm ID contains the kek encryption algorithm (and any associated
parameters) to be used. Any parameters supplied by params
are ignored. The supplied kek key encryption key already
has to be the one derived from a password (if PBE is used).
Since PWRI-KEK requires the usage of initialization vectors it only may
work properly with kek ciphers and modes using theirselves an iv (e.g.
AES or TripleDES in CBC mode). For that reason it is not possible to implement
PWRI-KEK in really algorithm independet manner. For instance, the RC2
algorithm not only uses an iv, but also a second parameter from which
the effective key length is calculated. So a RC2 cipher in CBC mode
has to be initialized with iv and the effective key length parameters.
As seen from above, the PWRI-KEK algorithm initializes decryption
algorithm three times, but only the last (innermost)
decryption phase uses the iv included in the kek algorithm id. For
RC2 this means that the RC2 Cipher engine has to be initialized
three times with same effective key length (derived from the
kek AlgorithmID parameters) but different iv (only the last got
from the AlgorithmID parameters). For that reason this method
gets the algorithm parameters from the kek AlgorithmID and then
calls method setIv to convert the (RC2) AlgorithmParameters
into a (RC2) AlgorithmParameterSpec object containing the requested iv:
... AlgorithmParameters kekParams = kekEncrAlgID.getAlgorithmParameters(); byte[] iv = ...; AlgorithmParameterSpec kekParamSpec = setIv(kekParams, iv)For algorithms that only use an iv as parameter, method
setIv
simply returns an IvParameterSpec object with the
given iv.
Also unwrap step 1a from the key format verification cannot be implemented in algorithm independet manner:
1a. If the CEK byte count is less than the minimum allowed key
size (usually 5 bytes for 40-bit keys) or greater than the
wrapped CEK length or not valid for the CEK algorithm (eg not
16 or 24 bytes for triple DES), the KEK was invalid.
Ckecking if the CEK byte count is greater than the wrapped CEK is quite
easy, however looking if the CEK byte count is less than the minimum allowed key
size or not valid for the CEK algorithm requires information of the
kek algorithm itself. However, a violatoin of any of these two requirements
will be detected later when attemping to use the unwrapped CEK with
the cooresponding Cipher engine. Thus checking this could be omitted here.
unwrapKey in class SecurityProviderwrappedCek - the wrapped secret content encryption key to be unwrapped (decrypted)kea - the key (un)wrap (en/decryption) alglorithm to be used, PWRI-KEKkek - the key encryption key to be used for decrypting the encrypted content
encryption keyparams - any algorithm parameters required for initializing the cipher;
ignored for PWRI-KEKcekAlgName - the name of the content encryption cipher (required by
the unwrap method of a JCE cipher engine)
java.security.NoSuchAlgorithmException - if the requested algorithm is not available
java.security.InvalidKeyException - if the key encryption key is not valid
java.security.InvalidAlgorithmParameterException - if the parameters cannot be parsed
or are not valid
public java.security.spec.AlgorithmParameterSpec setIv(java.security.AlgorithmParameters params,
byte[] iv)
throws java.security.spec.InvalidParameterSpecException
unwrapKey for
obtaining an algorithm dependent parameter specification containing
the iv required by the PWRI-KEK unwrap algorithm as specified in RFC 3211 (Password-based
Encryption for CMS), section 2.3.2:
2.3.2 Key Unwrap
Key unwrapping:
1. Using the n-1'th ciphertext block as the IV, decrypt the n'th
ciphertext block.
2. Using the decrypted n'th ciphertext block as the IV, decrypt
the 1st ... n-1'th ciphertext blocks. This strips the outer
layer of encryption.
3. Decrypt the inner layer of encryption using the KEK.
Key format verification:
1a. If the CEK byte count is less than the minimum allowed key
size (usually 5 bytes for 40-bit keys) or greater than the
wrapped CEK length or not valid for the CEK algorithm (eg not
16 or 24 bytes for triple DES), the KEK was invalid.
1b. If the bitwise complement of the key check value doesn't match
the first three bytes of the key, the KEK was invalid.
Since PWRI-KEK requires the usage of initialization vectors it only may work properly with kek ciphers and modes using theirselves an iv (e.g. AES or TripleDES in CBC mode). For that reason it is not possible to implement PWRI-KEK in really algorithm independet manner. For instance, the RC2 algorithm not only uses an iv, but also a second parameter from which the effective key length is calculated. So a RC2 cipher in CBC mode has to be initialized with iv and the effective key length parameters. As seen from above, the PWRI-KEK algorithm initializes decryption algorithm three times, but only the last (innermost) decryption phase uses the iv included in the kek algorithm id. For RC2 this means that the RC2 Cipher engine has to be initialized three times with same effective key length (derived from the kek AlgorithmID parameters) but different iv (only the last got from the AlgorithmID parameters). For that reason this method is used to convert the (RC2) AlgorithmParameters got from the KEK algorithmID into a (RC2) AlgorithmParameterSpec object containing the requested iv:
... AlgorithmParameters kekParams = kekEncrAlgID.getAlgorithmParameters(); byte[] iv = ...; AlgorithmParameterSpec kekParamSpec = setIv(kekParams, iv)For algorithms that only use an iv as parameter,this method simply returns an
IvParameterSpec object with the
given iv.
params - the AlgorithmParameters (CAST128Parameters, RC2Parameters, RC5Parameters,
IvParameters, etc., or nulliv - the iv to be set
java.security.spec.InvalidParameterSpecException - if the parameter specification cannot
be builtpublic java.security.SecureRandom getSecureRandom()
iaik.security.random.SecRandom. By default this method
returns a new SecureRandom anytime when called. However, when a
SecureRandom has been explicitly set by calling method setSecureRandom, this SecureRandom is returned.
getSecureRandom in class SecurityProvider
public javax.crypto.SecretKey generateKey(AlgorithmID algorithm,
int keyLength)
throws java.security.NoSuchAlgorithmException
generateKey in class SecurityProvideralgorithm - the requested algorithmkeyLength - the length of the key to be generated, may be required for
algorithms with variable key size
NoSuchSuchAlgorithmException - if the key for the requested
algorithm cannot be created
java.security.NoSuchAlgorithmException
public java.security.spec.AlgorithmParameterSpec generateAEADParamSpec(AlgorithmID contentAuthEncAlg,
byte[] encodedAuthAttributes,
long inputLength)
throws java.security.InvalidAlgorithmParameterException
This method is called by AuthEnvelopedDataStream
before setting up the cipher for encrypting the content.
Parameters are only created if not already contained in the algorithm id. Only aes-ccm and aes-gcm according to RFC 5084 are supported, as well as ChaCha20Poly1305 according to RFC 8103 and AES-CBC-CMAC according to BSI TR-03109-1.
generateAEADParamSpec in class SecurityProvidercontentAuthEncAlg - the id of the content-authenticated encryption algorithmencodedAuthAttributes - the DER encoded authenticated attributes for building the associated data,
if not nullinputLength - the data input length (may be required by CCM which needs to
know the length of the input data in advance)
null if
contentAuthEncAlg already contains parameters
java.security.InvalidAlgorithmParameterException - if an error occurs when creating the parameters
public java.security.spec.AlgorithmParameterSpec generateAEADParamSpec(AlgorithmID contentAuthEncAlg,
byte[] encodedAuthAttributes,
byte[] mac,
long inputLength)
throws java.security.InvalidAlgorithmParameterException
This method is called by AuthEnvelopedDataStream
before setting up the cipher for decrypting the content.
Only aes-ccm and aes-gcm according to RFC 5084 are supported, as well as ChaCha20Poly1305 according to RFC 8103 and AES-CBC-CMAC according to BSI TR-03109-1.
generateAEADParamSpec in class SecurityProvidercontentAuthEncAlg - the content-authenticated encryption algorithmencodedAuthAttributes - the encoded authenticated attributes, maybe null
if no authenticated attributes are includedmac - the mac value; may be null if not available at the time when setting
up the cipher and therefore may have to be set later
for the AEAD AlgorithmParameterSpec created by this methodinputLength - the input data length; only required for CCM mode; -1 otherwise
null if no AlgorithmParameterSpec
has been generated (e.g. because no parameters are included in the algorithm id or
the algorithm is not supported)
java.security.InvalidAlgorithmParameterException - if the parameters cannot be created
public void setAEADMac(java.security.spec.AlgorithmParameterSpec paramSpec,
byte[] mac)
throws java.security.InvalidAlgorithmParameterException
This method is called by AuthEnvelopedDataStream
when the mac value is not available for setting up the cipher for decrypting the
content and therefore has to be "added" to the AEAD AlgorithmParameterSpec
after having read the (encrypted) content.
setAEADMac in class SecurityProviderparamSpec - the AEAD AlgorithmParameterSpecmac - the mac value
java.security.InvalidAlgorithmParameterException - if the mac cannot be setpublic static void turnOffIAIKProviderVersionCheck()
|
This Javadoc may contain text parts from text parts from IETF Internet Standard specifications (see copyright note). | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||||||
IAIK-CMS 6.0, (c) 2002 IAIK, (c) 2003, 2023 SIC