One advantage of using a dedicated cryptographic co-processor is to offload computation to reduce CPU usage. A typical example is using hardware to perform the Advanced Encryption Standard (AES) encryption and decryption operations in a Transport Layer Security (TLS) session.

TLS is most commonly used in conjunction with the Hypertext Transfer Protocol Secure (HTTPS) protocol. You use HTTPS every time you buy something online to protect your credit card information. Depending on your browser, you may notice a lock icon or a green bar to indicate when a web page is served over HTTPS. In a TLS session, the client, your browser, and the server will negotiate to use the same symmetric key. While there are several symmetric ciphers that can be negotiated, AES is one of the preferred choices.

In the crypto accelerator role, a cryptographic co-processor would perform the encryption and decryption of each TLS record. This offloads the main CPU to handle the processing of the network traffic and perform the intended application. The BBB actually has such a cryptographic co-processor. Texas Instruments (TI) crypto performance page for the AM335x, the processor on the BBB, shows the results of their benchmark tests with OpenSSL. Using AES with a 256 bit key size and operating on blocks of 8192 bytes, the measured throughput of data was 8129.19 kB/sec without using crypto acceleration. This test resulted in a CPU usage of 69 percent. However, using the crypto co-processor on the AM335x, they measured a throughput of 24376.66 kB/sec with a CPU usage of 41 percent. That's almost a 200 percent gain in throughput performance and a 40 percent drop in CPU usage!

If your embedded application's purpose is to perform a computationally intense calculation, using a cryptographic co-processor designed to offload the crypto processing can save your CPU cycles for your main program.

A major advantage of using hardware cryptography devices is that keys can be generated internal to the device and are designed to be difficult to remove. In the web server world, these devices are called Hardware Security Modules (HSMs). In April 2014, a major vulnerability was announced that affected the OpenSSL software, colloquially called heartbleed. The vulnerability was not a cryptographic one per se, but rather the result of a programming error called a buffer overrun. This vulnerability is unfortunately common in the C programming language, in which OpenSSL is written, because of the lack of automatic array bounds checking. It was possible for a client to exploit this error and view internal memory of the server, potentially discovering sensitive information. The code to fix this problem was shorter than this paragraph.

The scale and severity of this vulnerability cannot be overstated. The most damaging attack is if the server's private key was leaked. Knowing the private key, an attacker can impersonate the server, and clients could willingly disclose private information to the impostor. However, on a server with a HSM, the heartbleed vulnerability was more limited. Sensitive information, such as session cookies, would still have leaked via the software exploit. Yet the server's private key, which remains in the HSM, would not have leaked.

Since the hardware cryptographic co-processor runs as a physically separate machine, it is very difficult for software exploits running on the main processor to disclose secrets in the hardware module. In the embedded world, there are several chips that perform this key isolation feature.

A hardware cryptographic device is generally not configurable. This is usually by design but the implication is that it is difficult, if not impossible, to alter the cryptographic behavior of the device. If you select a chip that performs encryption with a limited key size, you will not be able to upgrade the device with a stronger key size later. It is generally easier to update software-based encryption systems.

While an isolated crypto processor may reduce attacks or exploits from the software, it often allows more sophisticated hardware-based attacks. There are three categories of hardware-based attacks: noninvasive, invasive, and semi-invasive (Skoroboga, 2011). Noninvasive attacks treat the chip as a black box and attempt to manipulate the surrounding environment to perform an exploit. Successful non-invasive attacks include performing a Differential Power Analysis (DPA) to monitor the chip as it performs an encryption algorithm. By measuring the power usage during the encryption operation, it is possible to see the key through distinct power signatures. An invasive attack usually involves physically destroying the chip in some manner to gain access to its internals. Semi-invasive attacks may involve some sort of laser imaging to observe or interfere with the chip.

A final consideration is that while chip vendors may publish the interface to their device, the internals are often proprietary. This is similar to a software vendor who publishes the software programming interface, but provides only the compiled binary and not the source code. In this case, the chip is treated as a black box, and without a mechanism to verify the device, you have to trust that it is operating correctly. As cryptographic libraries are ported to unique microcontrollers by the open source community, this situation will hopefully improve.