Spotting the Sin During Code Review

If you havent identified the attack surface of an application (all of the input entry points), then its one of the first things you should do. Your threat models, if available, should already reflect the entry points. In most cases, network connections should probably just be using SSL/TLS, in which case you can follow Sin 10 for guidance for each network-based entry point you identify.

Otherwise , for each entry point that might possibly originate from the network, determine what mechanism is being used for confidentiality of bulk data, initial authentication, and ongoing authentication. Sometimes there wont be any, yet it will be determined an acceptable risk, particularly when e-mail is part of the system.

If there is confidentiality for a particular network connection, you should try to determine whether its doing the job. This can be tricky, because it often requires a reasonably deep understanding of the underlying cryptography. Heres some basic guidance:

Avoid doing this yourself. Use SSL or the Kerberos-based Application Programming Interfaces (APIs) Windows provides in the Distributed Component Object Model/Remote Procedure Calls (DCOM/RPC) libraries.
If not using an off-the-shelf solution, first make sure that the confidentiality technique is applied in all situations where confidentiality is appropriate. In most cases, you wont want to see any paths through the internal program where it is possible to get away without encrypting before sticking data on the wire.
If the bulk data encryption technique uses public key cryptography, theres almost certainly a serious misunderstanding of the cryptographers toolbox. Public key cryptography is so inefficient that the only encryption task its generally used for is encrypting random session keys and any necessary authentication data so that you can use symmetric cryptography. Not only is public key cryptography a huge denial of service risk, but also there are tons of things that can go wrong, particularly when the plaintext is anything other than a small random value. (The details are outside the scope of this book, but see the Other Resources section for sources of more information.)
Figure out what the underlying cryptographic cipher is. It should be a well-known algorithm and not a creation of the coder . If its homegrown,
its not worth using. This is a bug. Fix it. Legitimate symmetric ciphers come in two flavors: block ciphers and stream ciphers.

Advanced Encryption Standard (AES) and Triple Data Encryption (3DES) are examples of block ciphers . Either is good to see, as theyre the only two that
are secure current international standards. Data Encryption Standard (DES) is another example but it is crackable. If you dont see AES or 3DES, then you should check the current cryptographic literature to see whether the chosen algorithm is held in high regard.
Stream ciphers are essentially random number generators. They take a key and stretch it out into a long set of numbers , which you then XOR with the data you want to encrypt. RC4 is really the only popular stream cipher in use, though there is a long litany of others. None of these are well-recognized standards, and using a stream cipher is almost by definition bleeding edge, in that, with all of todays solutions, youre trading off security assurance to gain a marginal performance improvement that you almost certainly dont need anyway. If you still need to use a stream cipher, you should check the cryptographic literature to see what kind of problems there might be. For example, if you insist on using RC4 despite our reservations about its long- term viability, make sure its used in accordance with one of the preceding best practices. In general, its better to use a block cipher in a mode that behaves like a stream cipher (see following point).

If youre using a block cipher, determine what mode of operation is being used. The most obvious mode is to just break the message into blocks and encrypt each of those blocks separately, which is known as electronic code book (ECB) mode. This mode is insecure for general use. There are a bunch of modes that are much better regarded, including new modes that provide both confidentiality and ongoing authentication, particularly GCM and CCM. There are also classic modes such as CBC, CFB, OFB, and CTR (counter) that dont provide ongoing authentication. Theres generally no real good reason to use them if youre building your own application, and there are lots of downsides, such as having to provide your own message authentication.

Note

There are dozens of new cryptographic modes floating around academia that provide both encryption and authentication, but there are only two modes with real traction: CCM and GCM. Both are IETF-approved modes for IPSec. CCM is in the new 802.11i wireless security standard. GCM is entrenched in the new 802.1ae link security standard; it is newer and more suitable for high-speed applications. Both are good for general-purpose application development.

Some people use ECB or a stream cipher because theyre worried about cascading errors. Thats a fools game, because if authentication fails, you can never be sure if its due to an attack or an error. And, in pretty much every practical situation, its far more likely to be an attack. The better approach is to break the message down into a set of smaller messages that are individually authenticated. Plus, many block cipher modes such as OFB, CTR, GCM, and CCM have the exact same error propagation properties as ECB and stream ciphers.
Look to make sure that the attacker isnt going to be able to guess the underlying key material. At some point, this is going to have to involve some random data (often generated during a key exchange protocol). Keys generated from passwords are probably a bad idea.
If youre using a stream cipher, its important that keys can never be reused. When youre using a block cipher, its important that the combination of a key and an initialization vector (IV) cant be reused. (Generally, IVs are reset with every message.) Check to make sure that these things arent possible, even if the system were to crash.
If youre using CBC mode, the IV also needs to be at least cryptographically random (see Sin 18).

We cover making sure suitable initial authentication mechanisms are in place in our discussions of other sins. For ongoing authentication, use the following guidance:

As with block ciphers, make sure that message authentication applies to every message, and that it is actually checked on the receive side. If the check fails, the message should not be used.
Make sure that the schemes are reputable schemes. For public key cryptography, this should be either Secure MIME or PGP digital signatures. For symmetric key cryptography, this should be either a well-known block cipher mode that provides both encryption and authentication (for example, GCM or CCM) or a well-known message authentication code (MAC), particularly CMAC (Cipher MAC, a NIST-standardized message authentication code using a block cipher, primarily used with AES) or HMAC (used with a well-known hash function such as the SHA family or MD5).
Just like with confidentiality, look to make sure that the attacker isnt going to be able to guess the underlying key material. At some point, this is going to have to involve some random data (often generated during a key exchange protocol). Keys generated from passwords are probably a bad idea.
Be sure that the authentication scheme is used to prevent against capture-replay attacks. For connection-based protocols, the receiver needs to check some kind of message counter to make sure it is always incrementing and, otherwise, refuse the message as invalid. For connectionless protocols, there must be some other mechanism that guarantees no repeats will be accepted; this will generally involve checking some unique information, such as a counter or sender-side timestamp. This is generally checked against a receive window, where duplicates inside the window are explicitly detected , and anything outside the window is rejected.
Make sure that encryption keys arent doing double duty as message authentication keys. (This often wont be a practical problem, but its much easier to be safe than sorry.)
Make sure that all data is protected using the authentication check, particularly when the data is used by the application. Note that if youre using a mode of operation that both encrypts and authenticates, the initialization value automatically gets authenticated (usually this is a message counter).