Uploaded image for project: 'XWiki Commons'
  1. XWiki Commons
  2. XCOMMONS-1140

Upgrade to Bouncy Castle 1.56

    XMLWordPrintable

Details

    • Task
    • Resolution: Fixed
    • Major
    • 9.0-rc-1
    • 8.4.3
    • Dependency Upgrades
    • None
    • N/A

    Description

      See https://www.bouncycastle.org/releasenotes.html

      Security Defects.
      
          Using unknown status with the ASN.1 CertStatus primitive could result in an IllegalArgumentException on construction. This has been fixed.
          A potentional NullPointerException in a precomputation in WNafUtil has been removed.
          PGPUtil.getDecoderStream() would throw something other than an IOException for empty and very small data. This has been fixed. 
      
      Additional Features and Functionality
      
          Support for the explicit setting of AlgorithmParameters has been added to the JceCMSContentEncryptorBuilder and the JceCMSMacCaculatorBuilder classes to allow configuration of the session cipher/MAC used.
          EC, ECGOST3410, and DSTU4145 Public keys are now validated on construction in the JCA/JCE and the light weight API.
          DSA Public keys are now validated on construction in the JCA/JCE and the light weight API.
          Diffie-Hellman public keys are now validated where parameters allow it.
          Some validations are now applied to RSA moduli and public exponents.
          The ASN.1 Object Identifier cache now uses a Concurrent HashMap for additional speed.
          AES-CCM MAC support has been added to the provider.
          Support for ChaCha7539 (ChaCha20 as defined in RFC 7539) and Poly1305 have been added to the provider.
          Support has been added for defining your own curves and making them available to the key generators and factories.
          Methods have been added for specifying that a PGPPublicKey/PGPPublicKeyRing is being encoded for export and trust packets are not required.
          Plain-ECDSA and SHA-3 support has been added to DefaultDigestAlgorithmIdentifierFinder.
          SHA-3 support has been added to BcDefaultDigestProvider.
          A higher level TLS API and JSSE provider have been added to the project.
      
      Security Related Changes and CVE's Addressed by this Release
      
          It is now possible to configure the provider to only import keys for specific named curves.
          Work has been done to improve the "constant time" behaviour of the RSA padding mechanisms.
          The GCM ciphers in the JCE and lightweight API will now fail if an attempt is made to use them for encryption after doFinal or without changing the IV.
          The constructor for IESParameterSpec that allows the use of cipher without a nonce has been deleted. See also details for CVE-2016-1000344, CVE-2016-1000352.
          Strict encoding enforcement has been introduced for ASN1Integer.
          CVE-2016-1000338: DSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of "invisible" data into a signed structure.
          CVE-2016-1000339: AESFastEngine has a side channel leak if table accesses can be observed. The use of lookup large static lookup tables in AESFastEngine means that where data accesses by the CPU can be observed, it is possible to gain information about the key used to initialize the cipher. We now recommend not using AESFastEngine where this might be a concern. The BC provider is now using AESEngine by default.
          CVE-2016-1000340: Static ECDH vulnerable to carry propagation bug. Carry propagation bugs in the implementation of squaring for several raw math classes have been fixed (org.bouncycastle.math.raw.Nat???). These classes are used by our custom elliptic curve implementations (org.bouncycastle.math.ec.custom.**), so there was the possibility of rare (in general usage) spurious calculations for elliptic curve scalar multiplications. Such errors would have been detected with high probability by the output validation for our scalar multipliers.
          CVE-2016-1000341: DSA signature generation vulnerable to timing attack. Where timings can be closely observed for the generation of signatures, the lack of blinding in 1.55 or earlier, may allow an attacker to gain information about the signatures k value and ultimately the private value as well.
          CVE-2016-1000342: ECDSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of "invisible" data into a signed structure.
          CVE-2016-1000343: DSA key pair generator generates a weak private key if used with default values. If the JCA key pair generator is not explicitly initialised with DSA parameters, 1.55 and earlier generates a private value assuming a 1024 bit key size. In earlier releases this can be dealt with by explicitly passing parameters to the key pair generator.
          CVE-2016-1000344: DHIES allows the use of unsafe ECB mode. This algorithm is now removed from the provider.
          CVE-2016-1000345: DHIES/ECIES CBC mode vulnerable to padding oracle attack. For BC 1.55 and older, in an environment where timings can be easily observed, it is possible with enough observations to identify when the decryption is failing due to padding.
          CVE-2016-1000346: Other party DH public key not fully validated. This can cause issues as invalid keys can be used to reveal details about the other party's private key where static Diffie-Hellman is in use. As of this release the key parameters are checked on agreement calculation.
          CVE-2016-1000352: ECIES allows the use of unsafe ECB mode. This algorithm is now removed from the provider.
      
      Security Advisory
      
          We consider the carry propagation bugs fixed in this release to have been exploitable in previous releases (1.51-1.55), for static ECDH, to reveal the long-term key, per "Practical realisation and elimination of an ECC-related software bug attack", Brumley et.al.. The most common case of this would be the non-ephemeral ECDH ciphersuites in TLS. These are not enabled by default in our TLS implementations, but they can be enabled explicitly by users. We recommend that users DO NOT enable static ECDH ciphersuites for TLS.
      

      Attachments

        Activity

          People

            tmortagne Thomas Mortagne
            tmortagne Thomas Mortagne
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: