Luna HSMs have many capabilities that are not certified by NIST. To be FIPS-compliant, the HSM must be set toFIPS mode, where any mechanisms or cryptographic operations that are not FIPS-certified are blocked from use. FIPS mode is set using HSM or partition policies as described below.
Setting FIPS Mode on the HSM
You can set the HSM to FIPS mode usingHSM policy 12:Allow non-FIPS algorithms. When this policy is set to0, algorithms that are not FIPS-validated are blocked from use on every partition on the HSM, and the HSM is operating in FIPS mode. There are two methods of setting this policy:
>The HSM SO can use a policy template to set the policy at initialization (seeSetting HSM Policies Using a Template). This method is recommended for auditing purposes -- it ensures that the HSM is in FIPS mode for its entire use cycle.
Cryptosystems using arithmetic inZp*include the Diffie-Hellman Key Agreement Protocol and the Digital Signature Algorithm (DSA). The multiplicative groupZp*uses only the integers between 1 andp- 1 (pis a prime number), and its basic operation is multiplication. Multiplication ends by taking the remainder on division byp; this ensures closure. The multiplicative groupZ11* uses the integers from 1 to 10. Multiplication inZ11* finishes by taking the remainder when the result is divided by 11. Here are some examples of multiplication inZ11*: 4 7 mod 11 = 28 mod 11 = 6 9 5 mod 11 = 45 mod 11 = 1. Thus inZ11*,4 7 = 6and9 5 = 1. Notice that both the calculations shown have answers between 1 and 10.
Multiplicative Inverses
Each numberxin a multiplicative group has a multiplicative inverse element in the group; that is an integerx-1such thatx x-1= 1in the group. InZ11*,9-1= 5since9 5 mod 11 = 1. In a multiplicative group, each element must have a multiplicative inverse. Consider the integers modulo the (composite) number 15. It is possible to define multiplication on the numbers from 1 to 14, always finishing with reduction modulo 15. With this system, the number 6 has no inverse, since there is no numberysuch that6ymod 15 = 1:
6 0 mod 15 = 0
6 1 mod 15 = 6
6 2 mod 15 = 12
6 3 mod 15 = 3
6 4 mod 15 = 9
6 5 mod 15 = 0
6 6 mod 15 = 6
6 7 mod 15 = 12
6 8 mod 15 = 3
6 9 mod 15 = 9
6 10 mod 15 = 0
6 11 mod 15 = 6
6 12 mod 15 = 12
6 13 mod 15 = 3
6 14 mod 15 = 9.
The reason for this is thatgcd(6,15) = 3 > 1; a numberxhas a multiplicative inverse inZn*only ifgcd(x,n) = 1. Only whennis a prime numberpwill all elements inZn* have a multiplicative inverse. ThusZp* is a group only whenpis a prime number.
Other operations
While multiplication is the main operation in the multiplicative groupZp*, other operations can be derived from multiplication. For example, the divisionx / ycan be performed as the multiplicationx(y-1)modp. InZ11*,7 / 9 = 7 9-1= 7 5 mod 11 = 35 mod 11 = 2. It is also possible to define exponentiation inZp*as repeated multiplication. For example, the exponentiation 73inZ11can be achieved by multiplying7 7 7 mod 11 = 343 mod 11 = 2.
At CloudFlare, we’re committed to making sure the encrypted web is available to everyone, even those with older browsers. At the same time, we want to make sure that as many people as possible are using the most modern and secure encryption available to them. Improving the cryptography used by the majority requires a coordinated effort between the organizations building web browsers and API clients and those working on web services like CloudFlare. Cryptography is a two-way street. Even if we support the most secure cryptographic algorithms for our customers, web visitors won’t get the benefit unless their web client supports the same algorithms.
In this blog post we explore the history of one widely used cryptographic mode that continues to cause problems: cipher block chaining (CBC). We’ll explain why CBC has proven difficult to use safely, and how recent trends in the adoption of secure ciphers by web clients have helped reduce the web’s reliance on this technology. From CloudFlare’s own data, we’ve seen the percentage of web clients that support safer cipher modes (such as AEAD) rise from under 50% to over 70% in six months, a good sign for the Internet.
What’s in a block cipher?
Ciphers are usually grouped into two categories: stream ciphers and block ciphers. Stream ciphers encrypt data on a bit-by-bit basis. Plaintext and ciphertext are always the same length. Examples of pure stream ciphers are RC4 and ChaCha20. Although RC4 isno longer considered secure, we can still rely onChaCha20as a secure stream cipher for use on the web, but it was onlyrecently standardizedby the IETF and therefore does not have broad adoption.
Unlike stream ciphers, which can encrypt data of any size, block ciphers can only encrypt data in "blocks" of a fixed size. Examples of block ciphers are DES (8-byte blocks) and AES (16-byte blocks). To encrypt data that is less than one block long using a block cipher, you have several options. You can either turn the block cipher into a stream cipher (using something called counter mode, more on this later), or you can include extra bytes as padding to align the data to the block size. If the data is longer than one block, then the data needs to be split into multiple blocks that are encrypted separately. This splitting process is where things get tricky.
The naïve approach to encrypting data larger than the block size is called Electronic Code Book (ECB) mode. In ECB mode, you split your data into chunks that match the cipher’s block size and then encrypt each block with the same key. ECB turns out to be a very bad way to encrypt most kinds of data: if the data you are encrypting has redundant portions, say an image with many pixels of the same color, you end up with the "Tux" problem (demonstrated below). If two blocks have the same value, they will be encrypted to the same value. This property lets an attacker know which plaintext blocks match by looking at the ciphertext blocks.
For example, here’s what a high-resolution version of Linux’s "Tux" looks when encrypted in ECB mode:
The fact that identical plaintext blocks are encrypted to identical ciphertext blocks gives an unwanted structure to encrypted data that reveals information about the plaintext.
One solution to this is to "chain" blocks together by taking the output of one encryption and mixing it into the input for the next block. There are several block cipher modes, but the one that was originally standardized in SSL (and continues to be used in TLS) is Cipher Block Chaining (CBC). In CBC, the plaintext of one block is combined with the ciphertext of the previous block using theexclusive OR operation (XOR). The first block is XOR’d with a randomly generated initialization vector (IV).
Decryption works by XORing the previous block of ciphertext (or the IV) into the output of the decryption.
CBC has some nice properties. The ciphertext produced by a block cipher is encrypted, so it (hopefully) looks random. In CBC, you’re mixing this random looking encrypted data into the plaintext, making it very unlikely that there will be patterns in the output. Another advantage is that decryption can be done in parallel to speed things up. However, CBC has proven to be more trouble than expected when used in the context of the HTTPS and the web.
How records are encrypted in TLS
TLS provides both encryption—via a cipher—and integrity—via a message authentication code (MAC). When SSL was originally designed, one open question was: should we authenticate the plaintext data, or should we encrypt and then authenticate the encrypted data? This is sometimes stated as MAC-then-encrypt or encrypt-then-MAC? They chose MAC-then-encrypt (encrypt the authenticated data) which has since proven to be the less than ideal choice.
In cryptographic protocol design, leaving some bytes unauthenticated can lead to unexpected weaknesses (this is known as theCryptographic Doom Principle). When encrypting data using a block cipher mode like CBC, the last block needs to be padded with extra bytes to align the data to the block size. In TLS, this padding comesafterthe MAC. (There is a TLS extension, described inRFC 7366, that enables encrypt-then-MAC, but it’s rarely implemented.)
A TLS record has the following format. Each one has an 8-byte sequence number that is stored and incremented on each new one. The encrypted part of a request needs to add up to a multiple of 16 bytes, but for the purposes of this post, let’s assume that this length is 64 bytes (4 blocks).
In TLS, valid padding looks like a number preceded by that number of copies of itself. So, if the number is 0x00, it’s repeated 0 times:
If the number is 0x02, it’s repeated 0x02 times:
To decode a block, decrypt the entire message, look at the last byte, remove it, and remove that many bytes of padding. This gives you the location of the HMAC.
To compute the MAC, take the sequence number, the 5-byte header, and the message, then HMAC them using the shared integrity key.
Padding oracle
The problem with this construction is that it is susceptible to a technique called the padding oracle attack. This attack was first reported against TLS bySergeVaudenayin 2002. A padding oracle is a way for an attacker with the ability to modify ciphertext sent to a server to extract the value of the plaintext.
Attackers don’t have to be an ISP or a government to get in the middle of requests. If they are on the same local network as their victim they can use a technique calledARP spoofing. By tricking the victim’s machine to forward data to the attacker’s machine instead of the router, they can read, modify and measure the time it takes for every encrypted message sent from the browser to the server. By injecting JavaScript into an unencrypted website the client is visiting, they can get the browser to repeatedly send requests to a target HTTPS site. The