What is the Difference Between Encryption and Authentication?

By: Gunter Fuchs

Not considering how to actually do encryption or authentication, it is fairly simple for a native Latin speaker (http://www.etymonline.com/index.php?term=authentic, http://www.etymonline.com/index.php?term=crypto) to distinguish between the two. We authenticate something to prove to the receiver of the “something” that it actually came from us. We encrypt a message so nobody, including us, can read it. Why do we authenticate or encrypt? We authenticate so that the receiver is assured that what she received came from us and not from an imposter. This “thing” can be an item – a coin or painting for instance, or a piece of information, an email attachment or a speed command to a uranium centrifuge. We encrypt information so that only the intended receiver(s) can understand it.

So that was simple. But why do computer gurus go through great efforts to provide means of information authentication? Wouldn’t encrypting information be enough? Couldn’t the sender just include its name and address in the information and then encrypt? Well, no. The problem is that although a “man in the middle” will not understand the information, he will still be able to change it. For instance, in computer communication protocols a destination address (port) might be at a fixed position in a message. An adversary could copy such a message when it is on its way through some wire, change this value randomly, and monitor its own port/s until one of these messages – though still garbled – arrives. Once the adversary has received one message, he can now inject the encrypted port value for his own port for every message. One message would not be enough for a hacker to perform decryption,  but many makes this possible.  Not only would an adversary then be able to decipher messages that were not meant for her, but she can now also “break the code”, meaning deduce the encryption key. And with that key in hand, she can now send messages that are not authentic.

Therefore, a secure communication consists of authenticating the message and encrypting it.  To learn more about the importance of protecting your trade secrets, check out this white paper.

Weighing the Benefits of Hardware- vs. Software-only Security

By: Steve Jarmusz

I have seen many software programs touting that they have security built into the code.  I don’t think having the algorithm in software is such a bad thing, but having the keys or roots of trust stored in a non-secure, external Flash device or internal non-volatile memory within the MCU is.    I think it leaves the system vulnerable to attacks.  I have learned that software-based security schemes often use the hardware accelerators that are in a MCU or they implement them in software.  We have seen hack shops in Asia that will extract the keys from a binary file for a nominal fee, so that is not secure.  Even if the engineers bought a microcontroller that has crypto accelerators inside, normally the hardware accelerators inside the MCU are not protected from tampering.    In contrast, hardware-based security schemes use a device that has been created specifically to address a particular security need.  Hardware devices usually have secure key storage so that the key cannot be read from the outside nor changed.  The algorithms used by these devices are developed in hardware in a way that is secure and tamper resistant.  Hardware devices usually have built-in protection mechanisms in case they are being attacked either environmentally or physically.  So in your next design, I highly recommend that you spend a little time to research hardware security.