-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
=======
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.
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
<http://www-cse.ucsd.edu/users/mihir/papers/cbc.html>.
[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
<http://www.cacr.math.uwaterloo.ca/hac/>.
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@xxxxxxxxxxxx
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@xxxxxxxxxxxx
(c) nCipher Corporation Ltd. 2005
All trademarks acknowledged. nCipher and payShield are trade
marks of nCipher Corporation Limited.
$Id: advisory13.txt,v 1.13 2006/03/08 10:22:19 marcus Exp $
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBRA8GM+/+6Nq6MPYJAQLzzQf8CIfR25MzkyRGT9XaGEF165088u2MWI1i
ppdiHIM6ecVDhFoDVDcchdqsE6ofjkaglzh8Kp699iUtZ5DDr9xoyd8LwBvDYR6q
ofARCVhwVWlijR9faDJn2euTo4KdEvmltAF41Aq9FV8kmbMjv4cuScRfzpNWL3Di
mvreXnuCDfBILJHzAaxc9up2yS5pzH9nZ68Pg8V5gTYp5tKLJlNWs4ZfHZLXyvAT
y0keA5u6KR9gx+oq6GKwRH9vFSYxyXbib/ig7t8OH6K5OB94s4M4OFuNlDi2DJyl
jNVP23xoqjuySwO6lQ68BEIRpfgzMVaqoUT0ht2eyaORtrLI2dN+Ag==
=z1kn
-----END PGP SIGNATURE-----
