WSS4J
  1. WSS4J
  2. WSS-300

SubjectKeyIidentifier (SKI) incorrectly calculated for 2048-bit RSA key

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.11, 1.6.1
    • Fix Version/s: 1.5.12, 1.6.2
    • Component/s: WSS4J Core
    • Labels:
      None
    • Environment:
      Tomcat 5, Solaris 10, Java 1.4 and Tomcat 6, Win XP, Java 6

      Description

      The crypto function to get the SubjectKeyIdentifier from an X509Certificate has incorrect hard-coded assumptions about the size of the encoded information, meaning the calculation of the SKI from a 2048-bit RSA key is incorrect.

      The method org.apache.ws.security.components.crypto.CryptoBase.getSKIBytesFromCert does not parse the DER encoding of information, but just tries to pick out the piece of the byte array that corresponds to the content of interest. However, that approach fails because the DER encoding is variable length, depending on the size of the data being encoded. e.g. a 1024-bit key in a DER BIT STRING takes 4 bytes header + 140 bytes data to encode, whereas a 2048-bit key takes 5 bytes header + 270 bytes data; the header is one byte longer for the larger key, so the data starts at a different point in the array.

      To fix this, the DER data structures should be properly processed, reading the DER header bytes to determine the length of each data element (that also allows the generalization of handling any X.509 encoded public key, rather than just RSA keys as currently coded).

      Attached is a suggested patch (against WSS4J 1.6.1) that implements this idea: it processes the SubjectPublicKeyInfo and SubjectKeyIdentifier DER-encoded byte arrays according to their ASN.1 definitions from RFC 3280/5280 to pick out the desired data bytes.

      1. X509SubjectPublicKeyInfo.java
        3 kB
        Linton Miller
      2. X509SubjectPublicKeyInfo.java
        3 kB
        Linton Miller
      3. test.cypto.properties
        0.3 kB
        Linton Miller
      4. rsa2048.jks
        0.9 kB
        Linton Miller
      5. rsa2048.jks
        0.9 kB
        Linton Miller
      6. DERDecoder.java
        7 kB
        Linton Miller
      7. CryptoBase.java.patch
        2 kB
        Linton Miller
      8. correct.xml
        2 kB
        Linton Miller
      9. client.wsdd
        0.9 kB
        Linton Miller
      10. broken.xml
        2 kB
        Linton Miller

        Activity

        Hide
        Colm O hEigeartaigh added a comment -

        Hi Linton,

        Could you supply a test-case for this issue?

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Hi Linton, Could you supply a test-case for this issue? Colm.
        Hide
        Linton Miller added a comment -

        Sorry. Should have included this in the original report.

        I'm still working with Axis 1, so this test example may have syntax or config options specific to that. I've attached client.wsdd with is the Axis config I'm using for my invocation which encrypts a message using the public key in the rsa2048.jks keystore (pointed to through test.crypto.properties).

        Also attached are incorrect XML from the existing library (broken.xml), and corrected XML generated using my patch (correct.xml). You'll see the difference is in the <wsse:KeyIdentifier> which is "XFHevNgcrUZHs16vJbyDftWt+uY=" for the existing library, when it should be "tgkZUMZ461ZSA1nZkBu6E5GDxLM=".

        It also came to my attention today that Java 1.4 uses the string "X509" rather than "X.509" as Java 5+ and Bouncy Castle use when identifying the format of PublicKey encoding. That causes an exception in my X509SubjectPublicKeyInfo class, which specifically tests only for "X.509". While that's perhaps not directly an issue given Java 1.4 is no longer support on the 1.6 release, I don't think it hurts to try and be accommodating in general, so I suggest the addition of a one line modification to my X509SubjectPublicKeyInfo class:

        @@ -27,7 +27,8 @@
        */
        public X509SubjectPublicKeyInfo(PublicKey key) throws WSSecurityException {
        super(key.getEncoded());

        • if (!"X.509".equalsIgnoreCase(key.getFormat())) {
          + if (!("X.509".equalsIgnoreCase(key.getFormat()) ||
          + "X509".equalsIgnoreCase(key.getFormat()))) {
          throw new WSSecurityException(WSSecurityException.UNSUPPORTED_SECURITY_TOKEN,
          "noSKIHandling",
          new Object[] { "Support for X.509-encoded public keys only" }

          );

        Show
        Linton Miller added a comment - Sorry. Should have included this in the original report. I'm still working with Axis 1, so this test example may have syntax or config options specific to that. I've attached client.wsdd with is the Axis config I'm using for my invocation which encrypts a message using the public key in the rsa2048.jks keystore (pointed to through test.crypto.properties). Also attached are incorrect XML from the existing library (broken.xml), and corrected XML generated using my patch (correct.xml). You'll see the difference is in the <wsse:KeyIdentifier> which is "XFHevNgcrUZHs16vJbyDftWt+uY=" for the existing library, when it should be "tgkZUMZ461ZSA1nZkBu6E5GDxLM=". It also came to my attention today that Java 1.4 uses the string "X509" rather than "X.509" as Java 5+ and Bouncy Castle use when identifying the format of PublicKey encoding. That causes an exception in my X509SubjectPublicKeyInfo class, which specifically tests only for "X.509". While that's perhaps not directly an issue given Java 1.4 is no longer support on the 1.6 release, I don't think it hurts to try and be accommodating in general, so I suggest the addition of a one line modification to my X509SubjectPublicKeyInfo class: @@ -27,7 +27,8 @@ */ public X509SubjectPublicKeyInfo(PublicKey key) throws WSSecurityException { super(key.getEncoded()); if (!"X.509".equalsIgnoreCase(key.getFormat())) { + if (!("X.509".equalsIgnoreCase(key.getFormat()) || + "X509".equalsIgnoreCase(key.getFormat()))) { throw new WSSecurityException(WSSecurityException.UNSUPPORTED_SECURITY_TOKEN, "noSKIHandling", new Object[] { "Support for X.509-encoded public keys only" } );
        Hide
        Linton Miller added a comment -

        I should also point out that openssl can be used to independently verify the desired value. The "-ocspid" option to openssl x509 will print the hex SHA-1 hash of the public key.

        The following command line will use that to display what the generated SKI for my example RSA key should be:

        keytool -exportcert -keystore rsa2048.jks -alias test -storepass password | openssl x509 -inform der -ocspid | grep 'Public key OCSP hash' | perl -ne 'split; print pack("H*",$_[4])' | base64

        Show
        Linton Miller added a comment - I should also point out that openssl can be used to independently verify the desired value. The "-ocspid" option to openssl x509 will print the hex SHA-1 hash of the public key. The following command line will use that to display what the generated SKI for my example RSA key should be: keytool -exportcert -keystore rsa2048.jks -alias test -storepass password | openssl x509 -inform der -ocspid | grep 'Public key OCSP hash' | perl -ne 'split; print pack("H*",$_ [4] )' | base64
        Hide
        Linton Miller added a comment -

        Unfortunately, the new SKITest test case doesn't test this fix. That's because the test certificate has the SKI extension, thus the getSKIBytesFromCert doesn't need to calculate it from the public key (using the new code), but simply reads the extension value. You need to generate test certificates that don't have the X509v3 Subject Key Identifier extension (like my attached example) to test this new code.

        Show
        Linton Miller added a comment - Unfortunately, the new SKITest test case doesn't test this fix. That's because the test certificate has the SKI extension, thus the getSKIBytesFromCert doesn't need to calculate it from the public key (using the new code), but simply reads the extension value. You need to generate test certificates that don't have the X509v3 Subject Key Identifier extension (like my attached example) to test this new code.
        Hide
        Colm O hEigeartaigh added a comment -

        Hi Linton,

        Could you change the license policy on the keystore you attached to this JIRA so that I can include it in the test-cases? Or supply one that meets the criteria you outlined?

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Hi Linton, Could you change the license policy on the keystore you attached to this JIRA so that I can include it in the test-cases? Or supply one that meets the criteria you outlined? Colm.
        Hide
        Linton Miller added a comment -

        Re-attach test keystore with license granted for inclusion

        Show
        Linton Miller added a comment - Re-attach test keystore with license granted for inclusion

          People

          • Assignee:
            Colm O hEigeartaigh
            Reporter:
            Linton Miller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development