report a bug for key usage?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

report a bug for key usage?

Lou Wynn

Hi,

When I use BC to read a keyring generated by GnuPG 2.1, I found that BC failed to recognize subkey types. I traced down to the followingpiece of code in PGPSecretKey.

Obviously, this is a known task from the "Note" of comments. Is there a way that I can push BC to use key flags to determine usage types? This problem prevents interoperability between BC and GPG.

   /**
     * Return true if this key has an algorithm type that makes it suitable to use for signing.
     * <p>
     * Note: with version 4 keys KeyFlags subpackets should also be considered when present for
     * determining the preferred use of the key.
     *
     * @return true if this key algorithm is suitable for use with signing.
     */
    public boolean isSigningKey()
    {
        int algorithm = pub.getAlgorithm();

        return ((algorithm == PGPPublicKey.RSA_GENERAL) || (algorithm == PGPPublicKey.RSA_SIGN)
                    || (algorithm == PGPPublicKey.DSA) || (algorithm == PGPPublicKey.ECDSA) || (algorithm == PGPPublicKey.ELGAMAL_GENERAL));
    }


-- 
Thanks,
Lou
Reply | Threaded
Open this post in threaded view
|

Re: report a bug for key usage?

Lou Wynn

More information. According to RFC 4880

https://tools.ietf.org/html/rfc4880#section-9.1

Implementations SHOULD implement RSA keys (1).  RSA
   Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be
   generated, but may be interpreted.

GnuPG always emits the value 1 for whatever a subkey is. But BC still outputs 2 and 3. This is on the emission side of keys.

On 01/04/2017 10:55 PM, Lou Wynn wrote:

Hi,

When I use BC to read a keyring generated by GnuPG 2.1, I found that BC failed to recognize subkey types. I traced down to the followingpiece of code in PGPSecretKey.

Obviously, this is a known task from the "Note" of comments. Is there a way that I can push BC to use key flags to determine usage types? This problem prevents interoperability between BC and GPG.

   /**      * Return true if this key has an algorithm type that makes it suitable to use for signing.      * <p>      * Note: with version 4 keys KeyFlags subpackets should also be considered when present for      * determining the preferred use of the key.      *      * @return true if this key algorithm is suitable for use with signing.      */     public boolean isSigningKey()     {         int algorithm = pub.getAlgorithm();         return ((algorithm == PGPPublicKey.RSA_GENERAL) || (algorithm == PGPPublicKey.RSA_SIGN)                     || (algorithm == PGPPublicKey.DSA) || (algorithm == PGPPublicKey.ECDSA) || (algorithm == PGPPublicKey.ELGAMAL_GENERAL));     }

-- 
Thanks,
Lou
-- 
Thanks,
Lou
Reply | Threaded
Open this post in threaded view
|

RE: report a bug for key usage?

Eckenfels. Bernd
In reply to this post by Lou Wynn
The isSigningKey() gives you only the structural analysis if the key can technically be used for signing. The actual key flags you have to interprete yourself. I suspect this won't be folded into isSigningKey for compatibility reasons. When you interpret the flags yourself you also need to handle master keys (with no flags) as a fallback.

--
http://www.seeburger.com
________________________________________
From: Lou Wynn [[hidden email]]
Sent: Thursday, January 05, 2017 07:55
To: [hidden email]
Subject: [dev-crypto] report a bug for key usage?

Hi,

When I use BC to read a keyring generated by GnuPG 2.1, I found that BC failed to recognize subkey types. I traced down to the followingpiece of code in PGPSecretKey.

Obviously, this is a known task from the "Note" of comments. Is there a way that I can push BC to use key flags to determine usage types? This problem prevents interoperability between BC and GPG.

   /**
     * Return true if this key has an algorithm type that makes it suitable to use for signing.
     * <p>
     * Note: with version 4 keys KeyFlags subpackets should also be considered when present for
     * determining the preferred use of the key.
     *
     * @return true if this key algorithm is suitable for use with signing.
     */
    public boolean isSigningKey()
    {
        int algorithm = pub.getAlgorithm();

        return ((algorithm == PGPPublicKey.RSA_GENERAL) || (algorithm == PGPPublicKey.RSA_SIGN)
                    || (algorithm == PGPPublicKey.DSA) || (algorithm == PGPPublicKey.ECDSA) || (algorithm == PGPPublicKey.ELGAMAL_GENERAL));
    }


--
Thanks,
Lou










SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

Re: report a bug for key usage?

Dominik Schuermann
Hi Lou,

keep in mind that Bouncy Castle's OpenPGP implementation requires you to
do a lot of stuff manually.

You can see our method to check for signing capability here:
https://github.com/open-keychain/open-keychain/blob/master/OpenKeychain/src/main/java/org/sufficientlysecure/keychain/pgp/CanonicalizedPublicKey.java#L66

which depends on getKeyUsage() which searches for the most recent
signature packet with the flag subpacket:
https://github.com/open-keychain/open-keychain/blob/master/OpenKeychain/src/main/java/org/sufficientlysecure/keychain/pgp/UncachedPublicKey.java#L301

You also need a proper key import method that verifies and checks
certificates and binding signatures etc.

if you want to use this code, please honor the license.

Cheers
Dominik



On 01/05/2017 10:49 AM, Eckenfels. Bernd wrote:

> The isSigningKey() gives you only the structural analysis if the key can technically be used for signing. The actual key flags you have to interprete yourself. I suspect this won't be folded into isSigningKey for compatibility reasons. When you interpret the flags yourself you also need to handle master keys (with no flags) as a fallback.
>
> --
> http://www.seeburger.com
> ________________________________________
> From: Lou Wynn [[hidden email]]
> Sent: Thursday, January 05, 2017 07:55
> To: [hidden email]
> Subject: [dev-crypto] report a bug for key usage?
>
> Hi,
>
> When I use BC to read a keyring generated by GnuPG 2.1, I found that BC failed to recognize subkey types. I traced down to the followingpiece of code in PGPSecretKey.
>
> Obviously, this is a known task from the "Note" of comments. Is there a way that I can push BC to use key flags to determine usage types? This problem prevents interoperability between BC and GPG.
>
>    /**
>      * Return true if this key has an algorithm type that makes it suitable to use for signing.
>      * <p>
>      * Note: with version 4 keys KeyFlags subpackets should also be considered when present for
>      * determining the preferred use of the key.
>      *
>      * @return true if this key algorithm is suitable for use with signing.
>      */
>     public boolean isSigningKey()
>     {
>         int algorithm = pub.getAlgorithm();
>
>         return ((algorithm == PGPPublicKey.RSA_GENERAL) || (algorithm == PGPPublicKey.RSA_SIGN)
>                     || (algorithm == PGPPublicKey.DSA) || (algorithm == PGPPublicKey.ECDSA) || (algorithm == PGPPublicKey.ELGAMAL_GENERAL));
>     }
>
>
> --
> Thanks,
> Lou
>
>
>
>
>
>
>
>
>
>
> SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
> Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
> Edisonstr. 1
> D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
> Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
> Fax: 07252 / 96 - 2222
> Internet: http://www.seeburger.de               Registergericht/Commercial Register:
> e-mail: [hidden email]               HRB 240708 Mannheim
>
>
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.
>
>
> This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.
>


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: report a bug for key usage?

Lou Wynn
On 01/05/2017 02:09 AM, Dominik Schuermann wrote:
> You also need a proper key import method that verifies and checks
> certificates and binding signatures etc.

Thanks Dominik for the code links. Can you also point me to sample code
that verifies certifications and signatures?

If I reuse the code, I'll definitely honor the license, but chances are
after I learn how to do it with BC I'll fix my code or write correct code.

--
Thanks,
Lou


Reply | Threaded
Open this post in threaded view
|

Re: report a bug for key usage?

Dominik Schuermann
On 01/05/2017 08:47 PM, Lou Wynn wrote:
> On 01/05/2017 02:09 AM, Dominik Schuermann wrote:
>> You also need a proper key import method that verifies and checks
>> certificates and binding signatures etc.
>
> Thanks Dominik for the code links. Can you also point me to sample code
> that verifies certifications and signatures?

canonicalize() in UncachedKeyRing:
https://github.com/open-keychain/open-keychain/blob/master/OpenKeychain/src/main/java/org/sufficientlysecure/keychain/pgp/UncachedKeyRing.java

>
> If I reuse the code, I'll definitely honor the license, but chances are
> after I learn how to do it with BC I'll fix my code or write correct code.
>

If you are developing mission-critical software consider getting an
external code review. OpenPGP is not easy to get right. You can see some
of our mistakes at
https://github.com/open-keychain/open-keychain/wiki/cure53-Security-Audit-2015

We plan to make an OpenPGP library out if these classes in the future,
but I cannot provide an ETA:
https://github.com/open-keychain/open-keychain/issues/1964

Cheers
Dominik


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Exception when migrating keypairs from nss to bc in fips mode

Julie Yao
In reply to this post by Lou Wynn
Hi,
I got exception when trying migrated a keypair from nss to bc in fips mode:

java.security.KeyStoreException: BCFKS KeyStore exception storing private key: java.lang.IllegalArgumentException: Key pair inconsistent
       at org.bouncycastle.jcajce.provider.ProvBCFKS$BCFIPSKeyStoreSpi.engineSetKeyEntry(Unknown Source)
       at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)

code:
....
Enumeration<String> e = fromKS.aliases();
            while (e.hasMoreElements()) {
                String alias = (String)e.nextElement();
                System.out.println("Processing alias: " + alias);
                if (fromKS.isKeyEntry(alias)) {
                    boolean isCert = fromKS.isCertificateEntry(alias);
                    System.out.println("is cert " + isCert);
                    Key key = fromKS.getKey(alias, fromnssDbPwd);
                    Certificate[] chain = fromKS.getCertificateChain(alias);
                    System.out.println("is key entry, chain length: " + chain.length);
                    toKS.setKeyEntry(alias, key, bcKeystorePwd.toCharArray(), chain);

                } else {
                    Certificate cert = fromKS.getCertificate(alias);
                    toKS.setCertificateEntry(alias, cert);
                    System.out.println("not a key entry, set certificate entry");
                }
            }


I generated keypair:
certutil -S -s "CN=julie" -v 6 -n juliek1 -k rsa -x -t "C,C,C" -m 1234 -d config/jetty/nssdb/

Thanks,
Julie
Reply | Threaded
Open this post in threaded view
|

Re: report a bug for key usage?

David Hook
In reply to this post by Lou Wynn

That's certainly surprising (not just because we missed it, we started on 4880 while it was still in draft so maybe it got swapped at some stage, I am surprised it actually says that). I'll organise to get it "fixed".

Thanks for letting us know.

Regards,

David

On 05/01/17 18:02, Lou Wynn wrote:

More information. According to RFC 4880

https://tools.ietf.org/html/rfc4880#section-9.1

Implementations SHOULD implement RSA keys (1).  RSA
   Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be
   generated, but may be interpreted.

GnuPG always emits the value 1 for whatever a subkey is. But BC still outputs 2 and 3. This is on the emission side of keys.

On 01/04/2017 10:55 PM, Lou Wynn wrote:

Hi,

When I use BC to read a keyring generated by GnuPG 2.1, I found that BC failed to recognize subkey types. I traced down to the followingpiece of code in PGPSecretKey.

Obviously, this is a known task from the "Note" of comments. Is there a way that I can push BC to use key flags to determine usage types? This problem prevents interoperability between BC and GPG.

   /**      * Return true if this key has an algorithm type that makes it suitable to use for signing.      * <p>      * Note: with version 4 keys KeyFlags subpackets should also be considered when present for      * determining the preferred use of the key.      *      * @return true if this key algorithm is suitable for use with signing.      */     public boolean isSigningKey()     {         int algorithm = pub.getAlgorithm();         return ((algorithm == PGPPublicKey.RSA_GENERAL) || (algorithm == PGPPublicKey.RSA_SIGN)                     || (algorithm == PGPPublicKey.DSA) || (algorithm == PGPPublicKey.ECDSA) || (algorithm == PGPPublicKey.ELGAMAL_GENERAL));     }

-- 
Thanks,
Lou
-- 
Thanks,
Lou

Reply | Threaded
Open this post in threaded view
|

Re: Exception when migrating keypairs from nss to bc in fips mode

David Hook
In reply to this post by Julie Yao

The private key doesn't actually implement RSAKey does it? You'll need to translate it into a spec first - I'd guess it is coming from a hardware provider, often these do not allow access to private values at all unless you have specifically allow it and even then you need to have the right type to get to them.

Regards,

David

On 06/01/17 16:32, Julie Yao wrote:
Hi,
I got exception when trying migrated a keypair from nss to bc in fips mode:

java.security.KeyStoreException: BCFKS KeyStore exception storing private key: java.lang.IllegalArgumentException: Key pair inconsistent
       at org.bouncycastle.jcajce.provider.ProvBCFKS$BCFIPSKeyStoreSpi.engineSetKeyEntry(Unknown Source)
       at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)

code:
....
Enumeration<String> e = fromKS.aliases();
            while (e.hasMoreElements()) {
                String alias = (String)e.nextElement();
                System.out.println("Processing alias: " + alias);
                if (fromKS.isKeyEntry(alias)) {
                    boolean isCert = fromKS.isCertificateEntry(alias);
                    System.out.println("is cert " + isCert);
                    Key key = fromKS.getKey(alias, fromnssDbPwd);
                    Certificate[] chain = fromKS.getCertificateChain(alias);
                    System.out.println("is key entry, chain length: " + chain.length);
                    toKS.setKeyEntry(alias, key, bcKeystorePwd.toCharArray(), chain);

                } else {
                    Certificate cert = fromKS.getCertificate(alias);
                    toKS.setCertificateEntry(alias, cert);
                    System.out.println("not a key entry, set certificate entry");
                }
            }


I generated keypair:
certutil -S -s "CN=julie" -v 6 -n juliek1 -k rsa -x -t "C,C,C" -m 1234 -d config/jetty/nssdb/

Thanks,
Julie