- I have AES cryptography already, so why do I need anything more? If I am encrypting, isn't that all the security I need?
- I have heard that security has rankings, and that they rank something like this: 1) SHA, 2) AES, 3) RSA, 4) ECC. Does Atmel have the highest ranking?
- Symmetric algorithms like AES and SHA use a single key for all products (e.g. the host and the clients), so if the key is "broken" once, it would then be broken everywhere. Why would I want that?
- How can I justify the cost of an additional device to put security in every system I produce?
- How do I protect the bus between the crypto device and microprocessor?
- How can you encrypt with a one way algorithm like SHA, and isn't XOR weak?
- I have heard that my system isn't secure unless I use a secure micro, is that true?
- How do I protect my valuable software IP?
I have AES cryptography already, so why do I need anything more? If I am encrypting, isn't that all the security I need?
AES is an algorithm that scrambles (i.e. encrypts) information. The scrambled information can then be transferred somewhere else or stored in encrypted form and will remain unusable until it is unscrambled (decrypted) into its original form.
AES requires a key to encrypt and the same key to decrypt. Both the transmitter of the encrypted information and the receiver of it must store that key and keep that key secret on both sides. If the key is not kept secret on either side then the information can be obtained by unintended outside parties, which defeats the whole purpose. So, securely storing the key is one of the most critical parts of security. The memory where the key is stored must be able to withstand attacks that try to read the key(s).
Hardware security devices, like Atmel's CryptoAuthentication devices, offer a method of protecting secret keys that restrict access and provide key generation and management. Hardware security is much stronger then software based security because of the defense mechanisms that are on hardware security devices that repel attacks of various types.
I have heard that security has rankings, and that they rank something like this: 1) SHA, 2) AES, 3) RSA, 4) ECC. Does Atmel have the highest ranking?
In essence, security is a function of two main critical factors:
- The length of the key used by the cryptographic algorithms
- The mathematical operations that are employed by the cryptographic algorithms.
The strength of security, therefore, depends on both the key size and the specific algorithms employed. So, any of these algorithms might be stronger or weaker than any other. Among most cryptographic experts, the following key sizes are considered to be approximately similar in strength: SHA-256, AES-128, RSA-3072 and ECC-256. The letters depict the algorithm (e.g. SHA) and the numbers after the dash represent the length of the key (e.g. -256).
These important industry standard algorithms are all used in different ways depending on the application, and many cryptographic systems even use several types of algorithms together to optimize the benefits of each for higher security and operational efficiencies (such as speed).
Symmetric algorithms like AES and SHA use a single key for all products (e.g. the host and the clients), so if the key is "broken" once, it would then be broken everywhere. Why would I want that?
The secret to understanding cryptography is that operations always depend on keeping secrets (literally), and that means keeping the secret keys secret. Secure storage of the secrets (i.e. keys) is what maintains a system’s integrity regardless of the algorithm.
Fortunately, because of clever cryptographic engineering it is not necessary for all systems using symmetric algorithms to store the exact same key, even though this may sound counter-intuitive. Using a technique called “key diversification” each client in the system can store a unique key that is derived from its unique serial number and the key in the host (i.e. the root key). During the authentication process with diversified keys the client sends the host the client’s diversified key and the its unique serial number. The host can then derive the root key from that serial number and that diversified key and compare that derived root key to the host’s stored root key. If the stored and derived root keys match then the host knows that the client is real (i.e. authenticated).
Regardless of the algorithm type, crypto protocol, or system architecture, the best solution is to prevent the break in the first place by using high security hardware key storage.
How can I justify the cost of an additional device to put security in every system I produce?
Adding security into a system is similar to buying insurance. The cost of a security breach is analogous to the cost of an accident, fire, earthquake, or worse. The small cost of adding a crypto device ensures that future catastrophic costs are not encountered.
Some of the benefits of adding a crypto device are as follows:
- Increase revenue that can be lost due to the sale of unauthorized products (e.g. clones).
- Improve revenue by preventing authorized subcontractors from using unauthorized sales channels (i.e. selling clones in the gray market).
- Minimize the cost of warranty support for non-authentic (i.e. cloned) products.
- Enforce product and manufacturing licensing agreements to gain royalty income as agreed to.
- Increase product family revenue by allowing only authorized accessories to operate on an OEM's system.
- Conform to regulatory requirements such as HIPAA for medical information privacy in the US, cross-border medical authentication recommendations in Europe, and new FDA recommendations in the US for wireless medical device authentication.
How do I protect the bus between the crypto device and microprocessor?
The question often comes up about how to ensure that the communication between the crypto device and the host MCU is not attacked by a man-in-the-middle. In order to prevent a hacker from manipulating the bus between the two chips, the "Authentication OK" signal (i.e. the Boolean response) can be uniquely encrypted by the crypto IC.
One way to secure the bus between the crypto IC and MCU is to perform an authentication on the result of crypto calculation on crypto device (this is called the CheckMAC function). The idea is to make sure that when the authentication (i.e. crypto) device puts out the Boolean response (which means "True" or "False", or one or zero) from the Check MAC operation that the response cannot be tampered with.
The following paragraph explains in detail how that is done on a technical basis. However, the simple point here is that the Atmel’s CryptoAuthentication devices contain a built-in mechanism to prevent an attack on the bus between the device and the MCU by effectively encrypting that communication.
All the Atmel devices have a method of protecting the single Boolean bit that comes from the authentication chip to the microprocessor. It involves using the second key that is both stored in the CryptoAuthetication device and compiled into the code. After the successful completion of the "CheckMAC" operation, the second secret is copied into the TempKey register. Then the MCU sends over a unique number (for example, time of day), which is then combined with that second secret using SHA and returned to the MCU.
The software on the MCU does the same combination using the compiled secret to see if it agrees with the result from the authentication device. This is beneficial, because it means that you cannot just put a simple switch in the wire between the two and always send a 1 (i.e. "True").
The Atmel cryptographic ICs can also be set up to implement a secure boot with any MCU. In this mode the devices confirm the authenticity of downloaded code.
How can you encrypt with a one way algorithm like SHA, and isn't XOR weak?
Many encryption algorithms like DES and AES use the XOR function as a key part of their implementation. Those algorithms use a secret key to produce code that is XORed with the data in order to encrypt or decrypt that data. The secrecy of the encrypted data depends upon how well the crypto algorithm mathematically scrambles that code, and not upon the strength of the XOR function itself.
Hash algorithm-based devices (such as the ATSHA204) use the SHA256 algorithm in the same way to implement an encrypted transport of data between the crypto device and a microprocessor.
During an encrypted read operation the crypto device uses a random number that is hashed with an internal secret (i.e. the secret key) to create a result (i.e. a hash value or digest). That hash value (i.e. digest) is then XORed with the value to be sent out of the device. (In other words, to encrypt the plaintext, the plaintext is XORed with the hash of the secret key and a random number.) When that encrypted data is received outside of the crypto device, the receiver will need to know the secret (i.e. secret key) that was used in order for that receiver to reproduce the device’s internal value that he or she will XOR with the received encrypted data to mathematically reconstruct the plaintext.
Similarly, on an encrypted write operation the chip inserts data based on the XOR of the internal calculated result. The encrypted data sent to the device should be calculated using the same internal secrets or the chip will not contain the expected value.
Since a completely new random number is created for each and every encrypted transport, and because the hash of that random number with the secret key is used as the XOR code, then breaking such an encrypted transport would require actually breaking the SHA-256 algorithm itself or obtaining the secret key.
I have heard that my system isn't secure unless I use a secure micro, is that true?
Secure Microprocessors are a great solution if your entire system can be implemented inside the provided resources of the secure micro and the cost point of the product is appropriate for the system.
For today’s high performance systems, high-end microprocessors with external expandability or special purpose hardware are required for most solutions. So, secure microprocessors are typically used as a separate companion device to the system MCU. The security challenges then becomes two-fold: 1) Coupling the secure micro with the unsecure operations of the high performance MCU, and 2) Protecting the bus between the two.
The best choice today to address those two issues is using a specialized crypto device (like Atmel's CryptoAuthentication) or a secure micro. One very important point is that a secure device is only as good as the protection of the stored secrets (i.e. keys) in a specialized crypto key storage device or in a secure MCU.
Special purpose Cryptographic IC devices (like CryptoAthentication) focus solely on secure authentication and key storage, and as a result they can be the more cost effective choice, and often far more secure.
The security functionality of a dedicated hardware authentication device is carefully tested and verified by the manufacturer (e.g. Atmel), so the system designer does not need to worry about bugs that could be exploited by attackers. In addition, with a hardware approach, the system designer does not need to be concerned about future software updates of the software-based solution that can later expose a security weakness.
How do I protect my valuable software IP?
The only way to fully protect the system software is to use a secure (i.e. smart card based) microcontroller and store the entire system code within the device. In that way it cannot be read, copied, or modified by an attacker. However, due to cost and other concerns, this will not be an acceptable solution for most systems. On the other hand, a specialized cryptographic authentication IC can provide excellent protection at a low cost.
In order to stop others from copying the system firmware and producing duplicate products (i.e. clones), a crypto IC can be employed to match the firmware to legitimate products. Authorizing firmware can be done by sending challenges to the cryptographic IC regularly during normal operation and then checking for the correct response. If a system is build doesn’t include a correctly programmed crypto IC, the firmware will fail to operate, thus protecting against cloning.
If, in the above scheme, the firmware is updated on a regular basis and new challenge-responses are incorporated into the system, it becomes very difficult for a hacker to analyze the firmware and remove the authorization checks. If a remote connection is available, implementing some of the challenges randomly from a trusted backend server can make this nearly foolproof.
Processors like the Atmel ARM9 devices include an on-chip boot ROM. This ROM can be programmed to use a crypto IC to check a firmware signature stored in the external flash prior to executing that program. If unauthorized modifications have been made to the operating program, it will be immediately detected and system operations can be interrupted.
When system architects are looking to protect sensitive algorithm, data, or protocols, the same secure boot methodology can be used to decrypt the encrypted program module stored in the external flash. The decryption key can be stored in the crypto IC since there is often no secure storage in the system processor.