Resources

Ask us a question.

SA#13: CBC-MAC IV misleading programming interface

Application programmers using the nCore API to calculate and verify CBC MACs may have accidentally implemented a MAC protocol which fails to detect certain modifications to messages it is supposed to protect.

This advisory also available as PGP-signed plaintext.

nCipher Security Advisory No. 13
CBC-MAC IV misleading programming interface

Note

nCipher is publishing three advisories numbered 12, 13 and 14 simultaneously. You are advised to review all three before taking any remedial action.

Summary

Issue Description

1. Cause

All uses of CBC-MAC should use a fixed IV, by convention zero. The IV should not be transmitted as part of the message. The nCipher nCore API allows users to pass in a nonzero IV which may cause developers to implement vulnerable systems inadvertently.

2. Impact

An attacker could modify a message that has been protected with a vulnerable CBC-MAC protocol implementation without this being detected.

3. Who Is Not Affected

The following are not affected by this advisory or by advisories 12 or 14:

Any nCipher module supplied with or upgraded to V10 firmware 2.22.6.
Any nFast or nForce Ultra module - as these either have no nCipher key management or have modules with fixed firmware.
miniHSM PCI or any other product utilizing the miniHSM as these are supplied with firmware revision 2.22.6 or later.
Any nToken.
Any acceleration only module, that is all nFast modules except nFast-KM or nFast-CA modules which are key management modules.

The following are *not* affected by this advisory or by advisory 12 but may be affected by advisory 14:

Any nCipher module supplied with or upgraded to V9 firmware 2.12.x
The higher-layer or standard APIs:
- PKCS#11
The applications and products:
- Apache
- Entrust Authority
- IBM HTTP Server, Application Server, Tivoli Access Manager
- Microsoft IIS, CA, ISA
- SunONE Webserver (formerly called iPlanet)
- PayShield PCI, SCSI and net
- SecureDB
- DSE200 Document Sealing Engine
- Time Source Master Clock (TSMC)
- pdfProof

The following APIs from nCipher software CD versions before v9.0 are not affected by this advisory but are affected by advisory 14 and may be affected by advisory 12 if you use Diffie-Hellman keys:

The higher-layer or standard APIs
- Microsoft CAPI
- Crypto Hardware Interface Layer CHIL (also known as hwcrhk)
- OpenSSL
- JCE
The standard protocols:
- SSL/TLS

4. Who May Be Affected

You MAY be affected if you are using an application written directly to the nCipher nCore programming interface, in C or Java if that application uses CBC-MAC for custom message integrity functions.

The key types affected are:

    DES     CAST256     Blowfish    DES3    Rijndael   
    DES2    Serpent     SEED        CAST    Twofish

If your application does not use any of these keytypes for message integrity, then it is not affected.

HMAC keys and HMAC mechanisms are not affected.

Applications that use Diffie-Hellman keys are also affected by advisory 12.

5. How To Tell If You Are Affected

If you are an nCipher end-user and the above lists do not include your API, your application, or the product or protocol you are using, please contact nCipher support or your application vendor.

Information for Application Developers

1. Cryptographic Details

The CBC-MAC mechanisms specified and implemented in the nCore API perform the operation shown in this diagram. (View the diagram in a fixed-width font.)

       P_0       P_1           P_n
        |         |             |
        v         v             v            Where:
 IV -->(+)   +-->(+)   .....-->(+)
        |    |    |             |            [ E_K ]  encryption
        v    |    |             |                      with key K
     [ E_K ] | [ E_K ]       [ E_K ]
        |    |    |             |              P_i    message plaintext
        +----+    +----....     |                       block i
                                v
                               MAC             (+)    exclusive or

During MAC generation, the application programmer may specify an IV, or allow the module to choose one. The resulting M_CipherText structure contains both the IV and the final MAC. During verification, the application programmer specifies the IV and MAC together with the message plaintext.

This can lead an application designer to implement the following arrangement:

  --------------------------+     +-----------------------------
    SENDER                  |     |     RECEIVER
                            |     |
  Message                   |     |
  -------+------------------------------------+---------> Message
                           |     |            
           |                |     |             |
           v                |     |             v
  -----> Sign ------------------------------> Verify ---> OK?
  IV               CipherText: MAC, IV
  (Optional)                |     |
                            |     |
  --------------------------+     +-----------------------------

However, if the IV is transmitted as part of the message, rather than being fixed, an attacker can modify the first block of the message by making a corresponding modification to the transmitted IV. Since the value of the IV is not known in advance by the receiver this modification will not be detected:

  P_0' = P_0 (+) delta
  IV'  = IV  (+) delta
  ... leading to the same MAC as previously.

In order to prevent this attack, all uses of CBC-MAC should use a fixed IV, by convention zero. The IV should not be transmitted as part of the message

The current nCore API CBC-MAC mechanisms do not encourage their use in this secure manner. However, such a use is possible, and secure:

  --------------------------+     +-----------------------------
    SENDER                  |     |     RECEIVER
                            |     |
  Message                   |     |
  -------+------------------------------------+---------> Message
                           |     |            
           |                |     |             |
           v            MAC only, no IV         v
  0 ---> Sign -+-------------------------+--> Verify ---> OK?
  Fixed,                   |           /
  zero, IV       `->discard |     | 0--'Fixed,
                    zero IV |     |     zero IV
  --------------------------+     +-----------------------------

2. Application and protocol vulnerability checking

To determine whether your application is vulnerable, check for all the instances of a CBC-MAC verification. If all these verification are carried out with a fixed IV, which is not obtained from the transmitted message, then your application is not vulnerable.

If any verification is carried out with an IV obtained from an incoming message then your application is vulnerable. Please contact nCipher support who will assist with the remedial action.

The mechanisms affected are:

    DESmCBCMACi64pPKCS5      RijndaelmCBCMACi128pPKCS5
    DES2mCBCMACi64pPKCS5     TwofishmCBCMACi128pPKCS5
    DES3mCBCMACi64pPKCS5     CAST256mCBCMACi128pPKCS5
    CASTmCBCMACi64pPKCS5     BlowfishmCBCMACi64pPKCS5                    
    SerpentmCBCMACi128pPKCS5 SEEDmCBCMACi128pPKCS5

3. nCore API changes

nCipher have made the following changes to the API to reduce the risk of future applications being deployed with this vulnerability.

The version 9 release of firmware (2.18.x and later) and corresponding host side support software contains support for the following new mechanisms:

    DESmCBCMACi0pPKCS5      RijndaelmCBCMACi0pPKCS5
    DES2mCBCMACi0pPKCS5     TwofishmCBCMACi0pPKCS5
    DES3mCBCMACi0pPKCS5     CAST256mCBCMACi0pPKCS5
    CASTmCBCMACi0pPKCS5     BlowfishmCBCMACi0pPKCS5                    
    SerpentmCBCMACi0pPKCS5  SEEDmCBCMACi0pPKCS5

These perform the CBC MAC sign and verification functions with a fixed IV of all zeroes. This IV is implicit and not transmitted in the M_CipherText structure. These mechanisms do not suffer from the vulnerability described above; application developers are recommended to use them instead.

The module will choose these mechanisms as the default when Mech_Any is specified in the Sign command. Furthermore, the module will refuse to verify ciphertexts which use a vulnerable mechanism when Mech_Any is specified in the Verify command. (The old behaviour is retained when a vulnerable mechanism is specified explicitly; in these cases, the application is assumed to have checked the IV).

4. Further warning regarding CBC-MAC

The CBC-MAC algorithms are not recommended by nCipher for new designs due to their inherent security weaknesses. New designs should use a suitable HMAC mechanism. See, for example [BKR-CBCMAC], particularly sections 4 and 5; and [MVV-HAC], section 9.5.1 and particularly remark 9.62.

Where CBC-MAC is already deployed, careful consideration should be given to the protocols in use to determine the risks of successful forgery.

nCipher intends to remove the vulnerable mechanisms altogether in a future release. If you have any information as to any compatibility problems this might cause, please contact nCipher support.

5. References

[BKR-CBCMAC]
M. Bellare, J. Kilian and P. Rogaway, `The security of the cipher block chaining message authentication code', Journal of Computer and System Sciences, Vol. 61, No. 3, Dec 2000, pp. 362--399. Extended abstract in Advances in Cryptology - Crypto 94 Proceedings, Lecture Notes in Computer Science Vol. 839, Y. Desmedt ed, Springer-Verlag, 1994. Full version available from .

[MVV-HAC]
A. Menezes, P. Van Oorschot and S. Vanstone, `Handbook of Applied Cryptography'. The CRC Press series on discrete mathematics and its applications. CRC Press, 2000 N.W. Corporate Blvd., Boca Raton, FL 33431-9868, USA, 1997. ISBN 0-8493-8523-7. Available online from .

Software Distribution and References

You can obtain copies of this advisory, and supporting documentation, from the nCipher updates site:

http://www.ncipher.com/support/advisories/

Due to export control regulations, we are unable to make software updates generally available on the nCipher web site. Please contact nCipher Support to obtain updated software.

The v9 release of firmware (version 2.18.x) is fully validated to FIPS 140-2.

nCipher Support

nCipher customers who require updated software, support, or further information regarding this problem should contact support@ncipher.com.

nCipher support can also be reached by telephone:

Customers in the USA or Canada: +1 877 994 4008
Customers in all other countries: +44 1223 723666

Customers in all other countries outside of the USA and Canada can call the USA number in the event that they receive the advisory outside of UK support hours (08:00 - 16:30 GMT).

Further Information

General information about nCipher products: http://www.ncipher.com/

nCipher Developer's Guide and nCipher Developer's Reference http://www.ncipher.com/documentation.html

If you would like to receive future security advisories from nCipher, please subscribe to the low volume nCipher security-announce mailing list. To do this, send a mail with the single word `subscribe' in the message body to: security-announce-request@ncipher.com.

All trademarks acknowledged. nCipher and payShield are trade marks of nCipher Corporation Limited.

$Id: advisory13.txt,v 1.12 2006/01/24 17:29:16 mknight Exp $

More Resources