Re: [pkcs11] CKM_ECDH_AES_KEY_WRAP investigation

On 7/22/20 9:12 AM, Daniel Minder
      wrote:

    

    
      
      
      
      

        
All,

        
 

        
Dieter added a pointer
            to his last “Update to AES Key wrap specification_V2.docx�
            upload saying that I’m investigating Timo’s questions on
            CKM_ECDH_AES_KEY_WRAP in
            https://markmail.org/message/yzttolaqlbnts7dm
            So, here is my report.

        
 

        
Timo is right:

        
- The format of the
            public key that becomes part of the final
            CKM_ECDH_AES_KEY_WRAP output is not defined.

        
- CKA_EC_POINT requires
            DER encoding of the public key

        
-
            CK_ECDH1_DERIVE_PARAMS.pPublicData MUST accept the raw form,
            but only MAY accept DER encoded version. However,
            CKM_ECDH1_DERIVE is used internally by
            CKM_ECDH_AES_KEY_WRAP.

      

    
    

    

    
This is compounded by the fact that the wrapped key and the
      public key are one concantenated blob. This is a problem because
      it generates an implicit protocol. If the application where using
      this mechanism 'blindly', some other tool (not PKCS #11) would
      still need to understand this wrapped format to interoperate. The
      mechanism should have separated the public key and the wrapped
      key, but it didn't. 

    

    
bob

    

    
      

        

        
 

        
CKM_ECDH_AES_KEY_WRAP
            currently specifies for unwrapping: “Splits the input into
            two parts. The first part is the public key material of the
            transport key and the second part is the wrapped target key.
            The length of the first part is equal to the length of the
            public key material of the unwrapping EC key.�

        
 

        
If DER encoding was used
            the length could be directly taken from ASN.1 header and it
            would not necessary to look at the length of the public key
            of the unwrapping EC key. In that case, the last sentence in
            the specification does not make sense.

        
The length of the public
            key of the unwrapping EC key (L) is only needed if raw
            format is used. Then, the first part is either L+1 or 2*L+1
            octets long (compress or uncompressed/hybrid format), and
            the format used can be distinguished by the first byte.

        
 

        
What should NOT be done
            in my opinion: support both DER encoding and raw format. The
            reason is that there is seems to be quite inconvenient and
            error prone for a PKCS#11 provider/token to distinguish
            ASN.1 octet string from raw uncompressed format since the
            first byte is 04 for both of them and the length of the
            first part is not known.

        
 

        
It's probably easier to
            require DER encoding here since then a CKM_ECDH_AES_KEY_WRAP
            wrapping can be easily created manually.

        
And it’s possible to add
            additional checks on unwrapping since the length of the
            public key is encoded in the blob, which can be checked
            against the private key used for unwrapping.

        
(At the same time, we
            could raise the requirement for
            CK_ECDH1_DERIVE_PARAMS.pPublicData from MAY to SHOULD accept
            DER…)

        
 

        
The question is now: has
            any vendor already implemented CKM_ECDH_AES_KEY_WRAP and is
            using raw format for the first part?

        
 

        
Best,

        
Daniel

        
 

      

      

      
      

        Utimaco IS GmbH

        Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0,
        www.utimaco.com

        Seat: Aachen – Registergericht Aachen HRB 18922

        VAT ID No.: DE 815 496 496

        Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann
        CSO, Martin Stamm CFO

        

        This communication is confidential. If you are not the intended
        recipient, any use, interference with, disclosure or copying of
        this material is unauthorised and prohibited. Please inform us
        immediately and destroy the email.