1. CryptoAuthentication™
Real. Easy.

2. Agenda Cryptography Introduction
Use Cases for Hardware Security Devices
Authentication, Trusted Identification, Secure boot, Download Protection, Anti-cloning, Consumption tracking, and more
Crypto Authentication Product Portfolio
ATSHA204(A)
ATAES132
ATECC108(A)
FIPS certified Embedded Systems
Trusted Platform Module

3. Does Security Matter? What Happened?
Hackers loaded unauthorized code into system
Common system architecture to store program in Flash and let users download updated versions from the web
How Can Atmel Help?
Put ATSHA204 in system to enable firmware validation capability upon any software download or update event
Late 2011 hack where researchers asserted that they could change the internal firmware in an HP Laser Printer and cause it to catch fire. HP claimed otherwise.

4. Does Security Matter?

5. Does Security Matter? What Happened?
Hackers exploited bug in crypto code
Hard for every system designer to be a cryptographic expert, open-source crypto code may be imperfect
How Can Atmel Help?
Add ATSHA204 for:
Secure key storage
Hardware implementation of algorithm
Random number generator
In the case of an ECC signature using the ECDSA procedure, it’s a fatal error if the ephemeral key is ever repeated. Usually a random number generator is used to generate a new ephemeral key each time but for some reason Sony always used the same number when generating signatures. Unfortunately, it’s a property of the ECC math that the penalty for doing this is that the private key is revealed.
It’s not clear if Sony was unaware of the rules, if they left in some debug code or some other reason. Whatever, the consequence was quite unfortunate.

6. Concepts of Cryptographic Algorithms

7. Encryption vs. Authentication
Cipher Text
Decrypt
Text
Text
Only Receiver can see the text in the clear
Authentication
Sign
Signature
Verify
Text
Text
Receiver can determine identity of sender,
make sure text wasn’t changed

8. Hashing vs. Encryption Hash (1 Way) Encryption (2 Way)
Data is scrambled/compressed into a fixed length digest
Constant input always generates the same digest
Can be used to verify the identity of the sender
Can verify the integrity of the message - that it hasn’t been changed
Usually SHA, but AES can be used as a hash algorithm
Hash
(1 Way)
Encryption
(2 Way)
Data can be scrambled and unscrambled
Provides confidentiality so that data can only be understood by authorized users
Common algorithms: AES, DES, RSA, ECC

9. Symmetric Authentication
System B Compares the Hash of M with the Response to verify the shared Secret
System A
KEYSECRET
System B
KEYSECRET
SHA256
SHA256 M
Challenge
Symmetric
All Systems With the Same Secret K Can Create the Session Key
The Session Key Can Be Loaded into an Encryption Decryption Engine
This Provides for Data Confidentiality
Response
Notice System A and System B MUST Share Knowledge of a Secret Key
All Systems with Secret Key can create and verify

10. Verifies Message with the Signature and Public Key of the Signer
Asymmetric Authentication
Verifies Message with the Signature and Public Key of the Signer
KEYPRIVATE
KEYPUBLIC
Verify
Sign M
Signature
Message
Asymmetric
• Sensor Has a Unique Private and Public Key corresponding to it
• Only the Private Key stored in the CryptoAuth chip in the sensor can Sign the Message
• The Thermostat can use the sensor Public Key to Verify the Message
• This Provides for Data Integrity
The Signer has a unique Private Key
Only the System with the Private Key can Sign the message
All Systems can verify the signature
Verify uses only public data
Message to Sign
Signature generated by the private key
Public Key associated with the private key

11. Hardware Security System Use Cases

12. CryptoAuthentication
Mobile devices: Chargers, batteries, adapters, speakers, keyboards, etc.
Industrial devices: Sensors
IP Protection
Prevent copying/cloning of system and software, authenticate phone/tablet software to OEM hardware, manage licensing revenue
Secure Communication
Wireless Systems, Wired Systems (PLC, Ethernet, ...),
Trusted Operation
Secure boot to ensure that system works as desired – medical, industrial, metering
Encrypted downloads: ensure OEM approved software

13. Symmetric* Authentication Example
Symmetric Authentication occurs when host verifies that its key and the client’s key match. 
MCU
Not Verified
Verified
Response
Challenge
SecureStorage
Host
Client
HASH Function (SHA)
HASH VALUE (Digest) =?
Random Number
Symmetric Authentication uses the same key on the host and client and authentication occurs when a host verifies that its key and the client’s key match. The “sameness” of the keys on each side is how symmetric is defined, which makes perfect sense, right?
This diagram shows an authorization process between a host and client called Challenge-Response. In this case, both the client and host have an ATSHA 204 device inside and each device has the same secret key. Like you might expect from the name, challenge-response describes the essence of how this process works. The host sends a challenge and the client makes a response using cryptographic magic and then the host runs the same process and makes a comparison to see if it gets the same answer.
The next slide explains how the crypto magic trick is done.  
Verify
*With symmetric authentication the host and client always have the same secret key.

14. Asymmetric Authentication Phases
The authentication of ECC108 is done in two phases
First Phase: Verify Certificate Signature
Is the device certificate signed by my trusted certificate chain?
Perform ECDSA verify (signer public key, signature, digest of cert)
After First Phase, you can trust the device public key
Second Phase: Verify Private Key
Send random message to be signed by the device private key
Perform ECDSA verify (device public key, signature, random message)

15. Asymmetric Authentication
Phase 1  
Host Public
Key
Digest Function
Certificate
Data +
Verify Public Key  
Host requests & receives certificate from client
Host extracts signature, client’s public key, & certificate data. Then hashes certificate data to create a digest.
Host runs ECDSA Verify Calculation on its public key, digest & client’s signature. If it succeeds then client’s public key is verified, and can go to phase 2.
Moving to Asymmetric Authentication: Phase one of the Asymmetric authentication process called ECDSA starts with the certificate stored in the client. The client in this example uses an ATECC108 for this purpose. The host system contains a microcontroller that initiates the ECDSA process by asking the client to send over the certificate. Examples of a host would be the machine that the client is inserted into, wired to, or talks to such as a printer, refrigerator, cell phone, thermostat control block, etc.
Again, the goal of phase 1 is to verify the public key on the client.
Let’s go step by step to see how that is accomplished: At step number one the client sends the certificate to the host at the host’s request. At step number two the host takes the certificate and extracts the certificate data (which is made up of the dynamic tester data, the static boilerplate data, and the client's public key) along with the signature. It then runs the same hashing function on the certificate data that was that was run in the factory, creating a 32-byte digest. The hash function run in the host should have the exact same result (digest) as the one that was run the factory, if the client is real. Moving to step three, the digest made from the certificate data is input together with the host’s public key already stored in there, and the signature from the certificate into the ECDSA Verify calculation. If the ECDSA calculation is successful then the client's public key is considered to be real. Once verified as real that key can then be used in phase two. So, next let’s look at Phase 2.  

16.           Asymmetric Authentication Phase 2 ATECC108
Verify Private Key   
Host creates random number challenge
Host sends challenge to client.
Client uses ECDSA engine to sign random number with client’s private key.
Client sends signature to host
Host runs ECDSA Verify using client public key verified in phase 1, random number, & new signature from client. If it succeeds then the Private Key is verified.  
The goal of phase two is to verify the client’s private key.
Phase two starts with a what is called a “random challenge”. Random simply refers to a random number that is generated by the host, which is then sent to the client. That random number will be used to challenge the client. “Challenge” means that the host wants to test the client to see if it can send back a signature that will pass the ECDSA calculation that the host will run on it. By now you might have noticed that the ECDSA verify calculation requires three inputs: The first is some type of fixed length number. It can be a random number such as used in phase two, or a digest such as used in phase one. The second input is the public key of the client. The third input is a signature. Going step by step: In step four the host generates the random number. In step five it sends it to the client. In step 6 the client uses the ECDSA signature engine in the ATECC108 to create a signature using the random number and the client’s secret private key. In step 7 that signature is sent to the host. In step 8 that signature, the random number, and the client’s public key that was verified in phase one are put into the ECDSA verify calculation. If the calculation succeeds then the accessory (or client) is proven to be real because both the client's public key and private key have been verified. And that is how it is done. Keep in mind that the ATECC108 does the heavy lifting, and the tools that Atmel provides make it easy to program the microcontroller to do its part. The engineering and mathematics behind authentication using sophisticated algorithms may not be easy, but that does not matter to the user because Atmel makes it easy to implement cryptography without having to be a cryptography expert. That is what makes CryptoAuthentication real, easy.  

17. Asymmetric Authentication
The two phases of ECDSA put together
Host
Accessory (Client)  
MCU
ATECC108
Host
Public Key
Digest Function
Certificate
Data
Accessory
Certificate
Verify Public Key
Signature
Client Public Key
Client Public
Key
ECDSA
Verify
Calculation 
Fail
Success
Client
Private
Key
Random Number Generator
Random
Challenge
Challenge  
Verify Private Key 
Signature
ECDSA
Signature
Engine
ECDSA
Verify
Calculation  
Fail
Success

18. Authentication Can Mean Many Things
User Identity – Validate that a user is who he says he is without having to reveal the user’s secret. Authenticate serial numbers
Sensor Location – Identify which sensor, where it’s located, validate source of the control message
Data Integrity – Verify that the message (file/packet/data) hasn’t been compromised when in transit/storage
Consumables – Maintain OEM revenue flow (razor/razor blade business model). Ensure that device are not used beyond their expected life
Spare Parts – Verify only factory genuine parts are used

19. Secure Communication Secure Session Key Generation
Session Key Generation for Symmetric-key Based Systems
Tamper-resistant Hardware Security IC Provides Root of Trust
Achieve Both Machine Authentication and Secure Communications

20. Firmware IP protection - Method of Protection
Concept: Software Communicates with Security Device
Send challenge message to security chip, check response for correctness
Only systems with properly programmed security devices will work correctly
Goal: Increase Cost of Attack!
If properly implemented, each check in the code must be found and removed separately
Require a new and separate attack with each revision of program
So, How do you protect FW and SW by using an ATSHA204? Well, in it’s simplest form, a challenge is sent to the ATSHA204 device from either the microcontroller or the PC. If the Response from the Challenge comes back true, it is ok to run the FW or SW. We say that the code has been autheticated. If however, the response from the challenge sent comes back false, you know that something is not correct and the FW or SW should not execute. To add complexity, to this example, if you send a challenge randomly throughout the code to the ATSHA204, you increase the level of effort for the attacker to dissect the code to bypass the check. In order to achieve the goal, increased levels of complexity should be added to your system. Let me show you on the next slide how this can be accomplished.

21. Security Devices Can Help Prevent Piracy
Software communicates with security device
Send challenge message to security chip, check response for correctness
Only system with properly programmed security device will work correctly
Multiple checks in software
10, 100, 1000 – as many as are practical
Different values for each check
Be creative!
Use diverse methods to send challenge and deal with response
Some methods should include fixed challenge-responses, some should include random challenges and compiled in keys
Change methods with each software update
Use all key slots, check different set of slots with each version

22. Simple Example ATSHA204 in every system has same secret in Slot0
// 0x1234 is challenge to ATSHA204*
// 0xABCD is correct response from ATSHA204
. . .
if (sendChallenge(Slot0, 0x1234) != 0xABCD)
{ error(“System Fault”); exit(-1); }
ATSHA204 in every system has same secret in Slot0
Practically infinite number of possible challenges
Only one correct response for each challenge
Each system could optionally have unique challenge-response pairs compiled in
This code construct may be easy to find and remove via reverse compilation
*These examples show the challenge and response as a 16 bit integer for clarity and simplicity. They will actually be 32 byte arrays for ATSHA204.

23. Authentication Verified
Anti-Piracy Example Technique using
Fixed Challenge Response
MICRO
CLIENT
Challenge
RESPONSE
CHALLENGE
ad00 10e0 d467 25de 8c60 8f60 5b93 5f7e 2354 a436 cb f18d 03b2 d911 81cf
ad00 10e0 d467 25de 8c60 8f60 5b93 5f7e 2354 a436 cb f18d 03b2 d911 81cf
ad00 10e0 d467 25de 8c60 8f60 5b93 5f7e 2354 a436 cb f18d 03b2 d911 81cf
ATSHA204
SHA256
Secret Key
Response =?
68b1 282b 91de 2c05 4c36 629c b8dd 447f 12f0 96d3 e3c dc
68b1 282b 91de 2c05 4c36 629c b8dd 447f 12f0 96d3 e3c dc
Yes
Authentication Verified
But what if the authentication verification answer is no?
Select Insert > Header & Footer > Type Title in Footer field
03/14/2012

24. Slightly More Complicated Example
// 0x1234 is challenge to ATSHA204
// 0xABCD is correct response from ATSHA204
. . .
int resp, chal = 0x1200;
chal += 0x0034;
resp = sendChallenge(Slot0, chal);
answer += resp;
answer -= 0xABCD;
Vary the constructs
Use state variables as the challenge
Use responses as part of calculation, jump vector, etc.
An attacker with a logic analyzer on the bus may be able to record all the correct responses

25. Even More Complicated Example
Microcontroller
ATSHA204
Secure
Key
Storage
Challenges
Compiled
into Software 
Challenge 
SHA-256
Hash
Engine 
Intermediate Keys
Compiled
into Software
Unique
Nonce 
Date, Time, RNG, etc.
Intermediate
Keys  
SHA-256
Hash
Engine 
SHA-256 SW 
Response 
Do They
Match ?    No
Yes
Can’t be attacked with a logic analyzer

26. Measures that could be taken if the system fails the validation process
Send Error message
Blacklist a device
Make a device in-operable
Have code do something unexpected or incorrect (ex. Cell phone always dials wrong numbers)
Limit/Reduce functionality of device
Display message stating that the required (legitimate) software must be downloaded
Some other creative idea
These are possible ways to respond to Anti-Cloning/Anti-Piracy Authentication Failures using the ATSHA204.

27. No Limits to Programmer’s Creativity!
Multiple checks in software, each different
10, 100, 1000 – as many as are practical
Change methods with each software update
Program multiple slots, each version works differently
Use all the key slots & methods
Vary the slots used with date, revision number
Make sure that some methods require runtime analysis
Chain or combine one response as the next challenge
Use response as part of a jump vector or table pointer
Consider web-based system enablement
Server can use ATSHA204 dongle for secure checks
ATSHA204 includes password handler
May provide useful capability in some situations
Maintain blacklist of invalid serial numbers
Can be updated with software revisions
and so on…

28. Increase the Complexity
None MU
MU + CC FC
MU + CC + PA + CM
MU + CC + PA + CM + DC
CC + PA + CM + DC + RC
CC + PA + CM + DC + RC + TK
CC + PA + CM + DC + RC + TK + RK
RK = Rolled Key
TK = Move the Challenge to Temp Key
RC = Random Challenge Response
DC = Dynamic Challenge on the Stack
CM = Code Misdirection
PA = Periodic Authentications
CC = Chaining Challenge Responses
MU = Multiple Unordered Fixed Chall/Resp
FC = Fixed Challenge Response
Here we have a list of nine different ways to use the ATSHA204. Each one of these methods is no more complex than the other. This list is just an example of what we came up with. Your developer may have nine of their own or more which should be implemented with each software update. The key to this is make the code complex enough to thwart an attacker or make it too expensive. So if we view this from the bottom up. If you do one authentication to the ATSHA204, you have one point for the attacker to get through. If you however, chain the different ways together, you create more complexity for the attacker to figure and compile out the checks. The more authentications you do to the ATSHA204, the more secure your FW and SW.
Increased
Protection

29. CryptoAuthentication products

30. Crypto Architecture
Optimized for high security, ease-of-use and low cost
Isolates any attack to a single device
Attackers cannot see what’s inside
Tamper-hardened Hardware Boundary
Unique Serial Number
ECC / SHA /AES Cryptographic Engine
Standards based crypto engine between interface and memory
Monotonic Counters
Tracks number of authentications
Secured
EEPROM
Secured EEPROM for keys & data
High Quality Random Number Generator
What are some other innovations that make the Atmel devices so robust?
Please look at the red border which represents a tamper-hardened hardware boundary. This boundary contains defense mechanisms such as shields, regulators, clock generators, and other counter-measures so attackers cannot see what is inside.
All the devices employ the same basic architecture of secure EEPROM for keys & data with the crypto engine standing between the interface and memory.
A one-way counter tracks how many times the device authenticates. Even when the power is turned off, the count remains the same. All the devices include an internal high quality hardware Random Number Generator, which is required for every cryptographic protocol. In addition, all the products include a guaranteed unique serial number for identification and key diversification.
Required for every crypto protocol
I/O options simplify design in
Multiple
Serial I/O options

31. Hardware Security Features
ATMEL CryptoAuthentication
Strong Multi-Level HW Security:
Active shield over entire chip
All memories internally encrypted
Data independent crypto execution
Randomized math operations
Internal state consistency checking
Voltage tampers, isolated power rail
Internal clock generation
Secure test methods, no JTAG
No debug probe points, no test pads
No package or die identification
Designed to Defend Against:
Microprobe attacks
Timing attacks
Emissions attacks
Faults, invalid command attacks
Power cycling, clock glitches
Partial personalization attacks
Standard
Devices
Cannot achieve this level of security with software alone!

32. High Level Device Comparison
World Class Hardware Security to Complement Every Micro
ATSHA204
Standard SHA256 hash algorithm
Secure key storage (16 slots)
Turnkey authentication, validation, key derivation, password checking
Functionality for both Host and Client configurations
ATECC108
Full 256-bit Elliptic Curve Cryptography (ECC)
No requirement for secure storage in the host system
Fast execution reduces code and performance requirements
Complete compatibility with ATSHA204
ATAES132
Secure storage for both data (32Kb) and keys (16 slots)
Rich command set to support every system architecture
Drop-in compatibility with industry standard 32Kb Serial EEPROM

33. Where to Use ATECC108, ATSHA204 or ATAES132
Customers Who Are Most Price Sensitive – Use ATSHA204
Host hardware cannot be easily changed – Use ATECC108
Compatibility with Serial EEPROM is a benefit
All Three Parts use same packages & pinout when configured for I2C
Systems that need full software compatibility or SPI – Use ATAES132
All components of system come from same OEM – Use ATSHA204
Systems w/many partners, complex ecosystem – Use ATECC108
Need to Secure up to 4Kbytes of data for Fingerprints, Calibration data, Firmware blocks, etc.. – Use ATAES132

34. Standards-Based Security Targeting OS-Based Embedded Systems

35. What is a TPM?
TPM is a Hardware-based Key Storage device providing a “Secure Vault” for any Embedded System
Four Primary Capabilities
Platform Integrity
Authentication
Secure Communication
IP Protection
Asymmetric Algorithm (RSA)
Supports 512, 1024, & 2048 keys
SHA-1 Hashing & HMAC
Industry Standard Specification
Trusted Computing Group
In every commercial PC, most servers

36. TPM … Way Beyond PCs Anything on a network! LTE base stations Servers
Multifunction printers
Gambling / gaming machines
Access points
Smart appliances with network connectivity
Test & measurement devices
Mobile payment terminals
Inventory control terminals

37. Support Tools

38. ACES Demonstration/Evaluation Software
Evaluate
Educate
Design
A platform to exercise CryptoAuthentication devices
Demos & Wizards to visualize end uses
Learn the memory and commands of CryptoAuthentication devices
See properly formatted commands for firmware
Stores and reloads configurations
Works with any CryptoAuthentication kit

39. CryptoAuthentication Tools and Support
Stand alone Library for Atmel CryptoAuthentication Devices
ATSHA204
ATECC108
ATAES132 39

40. Logic Analyzer Built In Atmel Protocol Analyzer Saleae
Low cost Logic Analyzer with support for both I2C and Atmel’s Signal Wire Interface (SWI)
App note available at: 40

41. CryptoAuthentication Tools and Support
Application Notes
ATSHA204 Authentication Modes
ATSHA204 Single-Wire and I2C Seamless Debugging Using Saleae Logic Analyzer
Secure Session Encryption Key Exchange with ATSHA204
Secure Boot Simplified
Designing with CryptoAuthentication Client Devices
Application Brief: Analyzing Strength of Security
The ATECC108 supports all the functionality of the ATSHA204 41

42. AT88CK490 CryptoAuthentication Demonstration & Evaluation Kit
ATSHA204
ATECC108
ATAES132
Software: Atmel Crypto Evaluation Studio (ACES)

43. AT88CK101- ()CryptoAuthentication Development Kit
Development Tools Reduce Time to Market
Easily connect to any AVR or ARM development platform
100% support for Atmel MCUs and development kits
Complete Development Environment
Source code libraries and example code available for free at
Libraries fully tested for AVR micros
ACES Software Exploration tool
Ordering Codes based on package type
Evaluate and Develop with AT88CK101STK
* AT88CK101STK8-MAH (UDFN) shown 43

44. Embedded TPM Starter Kit!
Introducing Atmel’s
Embedded TPM Starter Kit!
Start sending commands to the TPM immediately
Includes…
TPM SMBus Module
Mounted on AT90USBKey Board
Standard A to Mini B USB device cable
Mini A to receptacle A USB host adapter
USB flash drive
Alternate 9V battery supply cable
Flash Drive includes Sample Code & All Necessary Documentation!

45. CryptoAuthentication Low Volume Personalization
The AT88CK9000 Board is design for stand-alone secure programming of CryptoAuthentication family.
The board support a XML configuration file generated by ACES and is securely stored within the programmer board.
For large annual volumes, contact Atmel for other solutions.
Ordering Codes based on package type
AT88CK9000-xxx 45