CryptoAuthentication™
Real. Easy.
1
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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
2
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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?
•
3
Put ATSHA204 in system to
enable firmware validation
capability upon any software
download or update event
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Does Security Matter?
4
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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:
5
© 2014 Atmel Confidential
•
•
Secure key storage
•
Random number
2014
generator
Hardware
implementation of
algorithm
CryptoAuthentication™
Concepts of
Cryptographic
Algorithms
6
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Encryption vs. Authentication
Encryption
Text
Encrypt
Cipher
Text
Decrypt
Only Receiver can see the text in the clear
Authentication
Text
Sign
Signature
Verify
Text
Receiver can determine identity of sender,
make sure text wasn’t changed
7
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Text
Hashing vs. Encryption
• Data is scrambled/compressed into a fixed length digest
• Constant input always generates the same digest
Hash
(1 Way)
• 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
• Data can be scrambled and unscrambled
Encryption
(2 Way)
• Provides confidentiality so that data can only be
understood by authorized users
• Common algorithms: AES, DES, RSA, ECC
8
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Symmetric Authentication
System
A
KEYSECRET
System
B
KEYSECRET
SHA256
SHA256
System B
Compares the
Hash of M with
the Response to
verify the shared
Secret
Challenge
M
Response
• Notice System A and System B MUST Share Knowledge of a Secret Key
• All Systems with Secret Key can create and verify
9
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Asymmetric Authentication
KEYPRIVATE
M
Sign
Verifies Message
with the Signature
and Public Key of
the Signer
KEYPUBLIC
Signature
Verify
Message
•
•
•
•
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
1. Message to Sign
2. Signature generated by the private key
3. Public Key associated with the private key
10
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Hardware Security
System Use Cases
11
© 2014 Atmel Confidential
CryptoAuthentication™
2014
CryptoAuthentication
• Authentication
• 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,
•
12
industrial, metering
Encrypted downloads: ensure OEM approved software
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Symmetric* Authentication Example
Symmetric Authentication occurs when host verifies that its key and the
client’s key match.

Host
SecureStorage
MCU
Verified
Not
Verified
Challenge
Client
SecureStorage
Random
Number
HASH
VALUE
(Digest)
HASH
VALUE
(Digest)
HASH
Function
(SHA)
HASH
Function
(SHA)
=?

Verify

Response
*With symmetric authentication the host and client always have the same secret key.
13
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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
•
14
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)
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Asymmetric Authentication
Phase 1
Host Public
Key
Digest
Function


Certificate
Data
+
Verify
Public
Key

 Host requests & receives certificate from client
extracts signature, client’s public key, & certificate
 Hostdata.
Then hashes certificate data to create a digest.
runs ECDSA Verify Calculation on its public key,
 Hostdigest
& client’s signature. If it succeeds then
client’s public key is verified, and can go to phase 2.
15
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Asymmetric Authentication
Phase 2




Verify
Private
Key
ATECC108

creates random number challenge
 Host
sends challenge to client.
 Host
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.
16
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Asymmetric Authentication
The two phases of ECDSA put together
Host
Host
Public Key
Digest
Function

Certificate

ECDSA
Verify
Calculation
Fail
17
© 2014 Atmel Confidential

Client Public
Key
Success
Random
Random
Challenge
Number
Generator
Verify
Private
Key
Certificate
Data
Client
Public
Key
ECDSA
Verify
Calculation
Fail
ATECC108
Accessory
Signature
Verify
Public
Key


MCU
Accessory (Client)
Client
Private
Key
Challenge

Signature

ECDSA
Signature
Engine
Success
CryptoAuthentication™
2014

Authentication Can Mean Many Things
18
•
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
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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
19
© 2014 Atmel Confidential
Communications
CryptoAuthentication™
2014
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
20
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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 challengeresponses, 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
21
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Simple Example
// 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 challengeresponse 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.
22
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Anti-Piracy Example Technique using
• Fixed Challenge Response
CLIENT
MICRO
RESPONS
E
ad00 10e0 d467 25de
8c60 8f60 5b93 5f7e
2354 a436 cb44 1486
f18d 03b2 d911 81cf
Challenge
CHALLENG
E
ad00 10e0 d467 25de
8c60 8f60 5b93 5f7e
2354 a436 cb44 1486
f18d 03b2 d911 81cf
ad00 10e0 d467 25de
8c60 8f60 5b93 5f7e
2354 a436 cb44 1486
f18d 03b2 d911 81cf
ATSHA204
Secret
Key
SHA256
Response
=?
68b1
4c36
12f0
8dc2
282b
629c
96d3
2484
91de
b8dd
e3c5
4463
2c05
447f
8797
3483
68b1
282b 91de 2c05
01000110010111100000
4c36
629c b8dd 447f
11110100010110010111
12f0
96d3 e3c5 8797
00111111010101001011
8dc2
2484 4463 3483
1110000111110010
Yes
Authentication Verified
•But what if the authentication verification answer is no?
23
© 2014 Atmel Confidential
Select Insert > Header & Footer
> Type Title in Footer 2014
field 03/14/2012
CryptoAuthentication™
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
24
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Even More Complicated Example
Microcontroller
Challenges
Compiled
into Software
Intermediate Keys
Compiled
into Software

Date, Time,
RNG, etc.
ATSHA204
Unique

SHA-256
Hash
Engine

Intermediate
Keys
Nonce

SHA-256
Hash
Engine


Response 
Do They
Match ?

No

Challenge 
SHA-256
SW

Secure
Key
Storage
Yes

Can’t be attacked with a logic analyzer
25
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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
26
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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…
27
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Increase the Complexity
CC + PA + CM + DC + RC + TK + RK
CC + PA + CM + DC + RC + TK
CC + PA + CM + DC + RC
MU + CC + PA + CM + DC
MU + CC + PA + CM
•
•
•
•
•
•
•
•
RK = Rolled Key
TK = Move the Challenge to Temp Key
MU + CC
RC = Random Challenge Response
DC = Dynamic Challenge on the Stack
MU
CM = Code Misdirection
PA = Periodic Authentications
FC
Increased
Protection
CC = Chaining Challenge Responses
MU = Multiple Unordered Fixed
Chall/Resp
None
• FC = Fixed Challenge Response
28
© 2014 Atmel Confidential
CryptoAuthentication™
2014
CryptoAuthentication
products
29
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Crypto Architecture
Optimized for high security, ease-of-use and low cost
Attackers cannot
see what’s inside
Standards based
crypto engine
between interface
and memory
Secured EEPROM for
keys & data
Tamper-hardened Hardware Boundary
© 2014 Atmel Confidential
Unique Serial
Number
ECC / SHA /AES
Cryptographic
Engine
Monotonic
Counters
Secured
EEPROM
Tracks number
of
authentications
High Quality
Random Number
Generator
I/O options
simplify
design in
30
Isolates any
attack to a
single device
Required for
every crypto
protocol
Multiple
Serial I/O
options
CryptoAuthentication™
2014
Hardware Security Features
• Strong Multi-Level HW Security:
ATMEL CryptoAuthentication
• 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
Standard
Devices
• Designed to Defend Against:
• Microprobe attacks
• Timing attacks
• Emissions attacks
• Faults, invalid command attacks
• Power cycling, clock glitches
• Partial personalization attacks
Cannot achieve this level of
security with software alone!
31
© 2014 Atmel Confidential
CryptoAuthentication™
2014
High Level Device Comparison
World Class Hardware Security to Complement Every Micro
•
ATSHA204
•
•
•
•
•
ATECC108
•
•
•
•
•
Standard SHA256 hash algorithm
Secure key storage (16 slots)
Turnkey authentication, validation, key derivation, password checking
Functionality for both Host and Client configurations
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
32
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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
33
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Standards-Based
Security
Targeting OS-Based
Embedded Systems
34
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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
•
35
© 2014 Atmel Confidential
CryptoAuthentication™
2014
TPM … Way Beyond PCs
•
•
•
•
•
•
•
•
•
•
36
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
© 2014 Atmel Confidential
CryptoAuthentication™
2014
Support Tools
37
© 2014 Atmel Confidential
CryptoAuthentication™
2014
ACES Demonstration/Evaluation Software
www.atmel.com/cryptokits
38
© 2014 Atmel Confidential
•
ACES
• Demo
• 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
CryptoAuthentication™
2014
CryptoAuthentication Tools and Support
• www.atmel.com
• Stand alone Library for Atmel CryptoAuthentication Devices
• ATSHA204
• http://www.atmel.com/tools/CRYPTOAUTHENTICATIONATSHA204DE
VELOPMENTLIBRARY.aspx
• ATECC108
• http://www.atmel.com/tools/CryptoAuthentication_ATECC108_Devel
opment_Library.aspx
• ATAES132
• http://www.atmel.com/tools/CRYPTOAUTHENTICATIONATAES132DE
VELOPMENTLIBRARY.aspx
39
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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:
http://www.atmel.com/Images/Atmel-8847-CryptoAuth-ATSHA204-SWI-I2CDebugging-Saleae-Logic-Analyzer-ApplicationNote.pdf
40
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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
•
41
© 2014 Atmel Confidential
The ATECC108 supports all the functionality of the ATSHA204
CryptoAuthentication™
2014
AT88CK490 CryptoAuthentication
Demonstration & Evaluation Kit
ATSHA204
ATECC108
ATAES132
Software: Atmel Crypto Evaluation Studio (ACES)
42
© 2014 Atmel Confidential
CryptoAuthentication™
2014
AT88CK101- ()CryptoAuthentication Development Kit
Evaluate and Develop with
AT88CK101STK
• 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 www.atmel.com/cryptokits
• Libraries fully tested for
AVR micros
* AT88CK101STK8-MAH (UDFN) shown
43
© 2014 Atmel Confidential
• ACES Software Exploration tool
• Ordering Codes based on
package type
CryptoAuthentication™
2014
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!
44
© 2014 Atmel Confidential
CryptoAuthentication™
2014
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
© 2014 Atmel Confidential
CryptoAuthentication™
2014
© 2014 Atmel Corporation. All rights reserved.
Atmel®, Atmel logo and combinations thereof, Enabling Unlimited Possibilities®, and others are registered trademarks or trademarks of Atmel Corporation or its subsidiaries. Other terms and product
names may be trademarks of others.
Disclaimer: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Atmel
products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND CONDITIONS OF SALES LOCATED ON THE ATMEL WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING
TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE
THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to
make changes to specifications and products descriptions at any time without notice. Atmel does not make any commitment to update the information contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and
shall not be used in, automotive applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.
46
© 2014 Atmel Confidential
CryptoAuthentication™
2014