Cryptography Basic for Chip Design Engineers
The purpose of cryptography is to assure data protection, authentication, and non-repudiation (so no one can deny they took part in a communication). While codes and encryption have existed in one form or another since ancient times, it’s thanks to advances in electronic cryptographic systems since the 1970s that today we enjoy things like secure e-commerce transactions and mobile communications.
When two people – or machines — want to exchange data privately, they must first encrypt the data. A number of algorithms are available for this purpose, each with different ways of treating the key used for encryption and decryption. This key is, if you’ll pardon the pun, the key to the figurative vault. It’s what the hackers are after. If they have the key, they can crack the encryption.
Over the past few decades, security researchers have developed solutions incorporating two types of cryptographic methods: symmetric-key cryptography, which uses private keys, and asymmetric-key cryptography, which uses both public and private keys.
Symmetric-key Cryptography (a.k.a. Private-key)
In a symmetric-key cryptographic system (the most common is AES – Advanced Encryption Standard), the same key is used for encryption and decryption. As an example, let’s say Alice wants to encrypt a message (also known as plain text) she is about to send to Bob. She uses a private key that turns her message into unreadable gibberish known as cipher text. When Bob receives the cipher text, he must use the identical private key to decrypt it back to plain text he can read.
This highlights one of the chief disadvantages of symmetric-key cryptography: a copy of the key must be distributed securely to each recipient in advance. For large systems this quickly becomes impractical. Furthermore, if Bob loses his key, he’s stuck.
Another drawback: if the key is stolen en route from Alice to Bob, the thief is able to not only decrypt Alice’s message, but is also able to decrypt messages sent by anyone else using the same key. As the number of message recipients grows, or the size of the group grows, so do the security risks associated with distributing the key.
A workaround to address this system-wide weakness in symmetric-key cryptography is to issue each device (or person) a unique private key. However, while this eliminates the problem of one stolen key compromising security for all participants, it introduces the challenge of how to securely distribute and maintain all the keys, and control who has access to them. Key management is often done with databases, which are subject to their own security risks.
Asymmetric-key Cryptography (a.k.a Public-key)
With asymmetric-key, or public-key cryptographic systems, Alice and Bob use different keys (and methods) to send and receive messages. These systems can provide key agreement, digital signatures, and/or key/data transport, and there are two major categories: an RSA-type system and a Diffie-Hellman + DSA – type system. You can read more about them in our introductory white paper on cryptographic security methods.
Asymmetric-key cryptographic systems are all based on the mathematical premise that every player has two mathematically-related keys: a private key and a public key. In all asymmetric systems, the public key can be derived from the private key, but it is computationally infeasible to derive the private key from the public key. This enables a user (in our scenario, Alice) to secure her private key but send her public key out into the world for anyone else to use.
For example, when an asymmetric method is used for a digital signature scheme, Alice encrypts her message using her private key and sends the message to Bob, who then verifies the message with Alice’s public key. Anyone else who receives the message can also verify it with Alice’s public key. Similarly, when an asymmetric system is used for a key agreement scheme, Alice and Bob exchange public keys over an open channel, and using those public keys and their own private keys, they can agree on a shared “secret” key that nobody else knows.
Selecting a Cryptographic System for Your Microprocessor
There are advantages and drawbacks to both symmetric and asymmetric cryptographic systems. The main benefit of symmetric systems like AES are that they are generally computationally inexpensive, however, once a deployment gets larger than a small office, the deployment costs vastly outweigh this benefit. And, as mentioned previously, the need for prior transmission of keys and the widespread consequences of key loss or theft are also major drawbacks.
On the other hand, with asymmetric systems, if one person’s private key is compromised, other users do not suffer any loss. It is for this reason that asymmetric methods are used by many applications that involve transmitting data from one sender to several recipients (e.g. websites and secure email) to secure communications. And while asymmetric systems are computationally intensive and slower than symmetric systems, they ease deployments by solving the shortcomings of key management and key distribution that plague symmetric solutions. The problem is that due to their intensive nature, asymmetric systems have been limited to larger computing platforms – until now.
If you’re designing 8-bit or 16-bit processors, or designing an embedded device that uses them, your criteria for the cryptographic system you apply will most likely include:
- Low power consumption, especially for processors running on battery-powered platforms
- A small footprint in FPGA and ASIC implementations
- Relatively fast run times to enhance usability
- Quantum-resistance, as the threat of quantum attacks will likely be realized for many devices with a long lifespan (e.g. IoT devices)
SecureRF has public-key security solutions that meet the above criteria. Our quantum-resistant, cryptographic algorithms, ideally-suited for constrained environments, provide identification, authentication and data protection. Find out more about the technology and mathematics behind cryptography in general, and our methods in particular, by reading our technical papers. For a demo of how our solutions might work for your application, please contact us.
