23064 SEC2

Anatomy of a Secure System

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 1
 Class Objectives
Abstract

• Anatomy of a Secure System –

• Prior knowledge of the fundamentals of cryptography is required.
• A prerequisite for this class is the Crypto Primer (SEC1) or equivalent knowledge.
• This class will prepare you to create a secure system using a layered security approach called
“defense in depth”.
• We will discuss
• suggested hardware,
• suggested cryptographic functions,
• attributes all connections should have.
• How to implement these in secure networks used for a variety of applications:
• We will discuss access control as an example

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 2
 Agenda of this class

• Developing a Security Thought Process

• Key Management
• When to use Symmetric vs Asymmetric Cryptography
• When to use Encryption
• The Three “Vital 3”
• The “Vital 3” of Hardware Requirements
• The “Vital 3” of Cryptographic Functions
• The “Vital 3” for all Connections

• Use-Case example
• Networks
• Specifically, an Access Control network

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 3
© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 4
 Embedded vs Cyber
a matter of where implemented and what it’s protecting against
Layered Cybersecurity
implemented in software Embedded Security implemented
in firmware/hardware
Rootkits, viruses, worms, & trojans

Unlicensed Programs

Zero Day Threats

Command and control messaging

Apps that look/behave like threats

Attempted unauthorized system changes

Targeted attacks
Embedded Security is a secure boundary made up of
Firmware updates
Hardware & Embedded Firmware.
Identified threats of any type
It is a robust level of persistent security which is
Remnants or threats mostly stopped active for the entire life of the hardware, no matter the
software configuration(s).
Mutating Viruses

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 5
 The goal is platform resiliency
These 5 functions work in concert to provide effective high-level risk management

• Identify
• Designers define and prioritize security efforts
against anticipated threats
Embedded • Each element needs a unique identity
Security
• Protect
• Limit the ability of an adversary to cause a security
event
Advised
• Detect & Report
Cyber • Identify the occurrence of a security event
Security
• Respond
• Take action once a security event is detected

• Recover
• Restore capabilities and services that may have
been impaired

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 6
 Weaknesses we commonly encounter
Lack of security by design:
Security is too often an afterthought

Lack of education:
Security principles are not well understood and consequently incorrectly implemented

Mishandling of keys:
Keys are not securely contained and often left in vulnerable system memories

Secure coding practices are ignored:

Vulnerabilities are left open to adversaries

Risks from manufacturing are commonly overlooked:

CMs commonly overbuild and most can’t protect secrets even if they wanted to

Generally, what’s lacking is a sound “Security Thought Process”

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 7
 The Security Thought Process
Risk assessment and strategies for addressing those risks
• It begins with a risk assessment and strategies for addressing those risks
• Get your “ducks in a row” from the very start
• Learn the mindset and foundations of designing secure hardware

• Know what needs protection, why it needs protection, and who the adversaries are
• By understanding your adversaries, you’ll know what they are capable of doing and what
they will most likely do

• We highly recommend our lecture dedicated to understanding the risks and potential solutions:

• “Crypto Key Storage - Challenges and Solutions”

• …an overview of the various methods by which attackers can retrieve keys, secrets and
code from integrated circuits and why software security implementations so often fail…
– Microchip Masters Class

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 8
 Why do Adversaries Attack?
• Gain access to your valuable data and/or infrastructure
• Identity, bank accounts, competitive data, cloning, etc…

• Use your infrastructure to work on their tasks

• “Hey! I’m working here!!!”

• Hide behind your infrastructure while hacking other systems

• Industrial espionage – sabotage

• Recruit your devices into an evil botnet

• Capable of launching DDOS attacks (e.g. Marai)

• Plain old Mischief

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 9
 Who are these adversaries?
Generally, there are three types

• Opportunists
• Clever people who defeat minor defenses to gain something for themselves
• Limited knowledge – Often use “canned” hacks from the internet
• The internet instructions for hacking early versions of Amazon’s Fire TV Stick is a great example
• Rarely innovative - If we leave the door unlocked, they think they have every right to go inside

• Educated hobbyists, Academia, to light industrial espionage

• Very clever people who enjoy the challenge posed by your defenses
• Many are “White Hat” hackers looking to pad their resume, help society, or seek attention
• Unfortunately, many are “Black Hat” hackers making mischief, mayhem, and possibly engage in extortion
• They can be somewhat innovative
• Typically their skills are from a “day job” in tech or academia

• Large Corporate or State-level hackers – Highly Motivated – Highly Skilled

• These extremely clever people use their skills and intellect as their sole means to earn a living
• The “Killer Whales” of the hacker community - Highly skilled professionals, backed by significant resources
• They are highly innovative – Performing organized sophisticated attacks with advanced tools they may have
invented for the sole purpose of hacking a particular device or communication

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 10
 What can we do about them?
• Opportunists
• Implementing just the vital foundations of security will keep them out
• Removing the opportunity = removing the opportunists

• Educated hobbyists, Academia, to light industrial espionage

• Defense The goal is secure your product as well as your ecosystem to address the most likely and damaging
threats your system faces
• Use a multilayered methodology – “Defense in Depth”
• Make a successful hack cost more than any value they gained

• Large Corporate or State-level hackers – Highly Motivated

• Any defense demands a coordinated and highly sophisticated active detection and response measures
integrated with a robust base of embedded persistent security and a robust ecosystem architecture to segregate
and control breaches (read all of this as: expensive!)

• Defense against these nearly unstoppable “killer whales” is not a subject of this presentation

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 11
 A multilayered methodology:
“Defense in Depth”
You may hear this referred to as the “Castle Approach”, which was the old term for it

• Defense in depth minimizes the probability that the efforts of malicious hackers will succeed
• Defense in depth is the coordinated use of multiple layers of security
• Like the layers of an onion, it extends from the hardware based foundation of a device and exists throughout the
entire ecosystem
This also includes…
• …why certain data is collected
• …how the data is stored
• …and behavior of users

• If one defense is breached, an adversary simply encounters another layer of defense

• Consider the case of encryption being used at the application layer as well as the transport layer
• The application data will already be encrypted before it gets to TLS
• If an adversary defeats the TLS encryption all they find is another encrypted data stream inside
• Defense in depth can be thought of as a series of frustrating, time consuming, walls of protection

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 12
 The way to think about Security
• Modern computing system architectures can also be thought of in layers
• The top layers are software
• composed of the operating system and applications

• The underlying layers

• composed of hardware, firmware and/or FPGA images

• And the physical layer

• Various security schemes, which are also structured in layers, need to be implemented
• Physical security – Its name implies its function

• Embedded security – Hardware enforced persistent security for keys and critical primitives

• Cybersecurity – Software based protection of internet-connected systems from cyberattacks

• CyberSecurity, if not anchored to the hardware in some way, is not as effective

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 13
 Cybersecurity –
Use Secure Coding Practices!
• Great place to start: Open Web Application Security Project (OWASP)
• The OWASP Secure Coding Practices Quick Reference Guide
• https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf

• Everything you
need to start:

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 14
 Embedded Security
Key/Secret Management Lifecycle
• “Key management” describes the operations needed to create, maintain, protect, and control
the use of keys.
• Keys have a life cycle; they’re “born,” live useful lives, and are retired
• Each phase of life may require different protections

• A Key Management plan needs to be an integral part of any secure ecosystem

• And like security itself, needs to be thought of at the beginning of any project

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 15
 Best Security Practices for Handling
Keys & Secrets
Isolate keys & secrets from users
Humans are the most unpredictable security risk

Isolate keys & secrets from software and firmware

Any unprotected MCU or MPU is hackable and any secrets stored in code are vulnerable

Isolate key & secret manipulation from the manufacturing phase

Not only from the supply chain equipment but also from the users in the supply chain

Keep critical crypto-primitives where the keys & secrets are: isolated
If algorithms dealing with keys can be hacked, adversaries can bypass the keys

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 16
 Select Truly Secure Devices
Two “Must-Have” properties

• Most certifications requires a device to demonstrate two must-have properties

1) Assurance the device implements valid algorithms
• NIST’s Cryptographic Algorithm Validation Program (CAVP) provides validation testing of
FIPS-approved and NIST-recommended cryptographic algorithms and their individual
components

2) Penetration testing of the device

• This is done at independent 3-party certified labs where they try to extract secrets using every
method currently known
• The result is a Common Criteria Joint Interpretation Library (JIL) rating

• Unlike FCC certifications, cryptographic device certifications do not transfer to

systems

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 17
 When to use Symmetric or
Asymmetric Cryptography
The most important question is:
• Does your system need to interoperate with any other vendor’s equipment?
• If your ecosystem will only contain devices you create, Symmetric is a great solution
• The security of a symmetric system relies on how well the key is protected
• If Alice shares her key with Bob, she cannot be assured Bob is protecting the key adequately
• If Alice is creating an enclosed system with no interoperability, there is no Bob

• If you require interoperability with other vendor’s equipment, consider Asymmetric

• With Asymmetric cryptography, the private key is never shared… ever
• Public keys and certificates are shared, but neither are considered secrets
• Alice, Bob, and/or anyone else will be the only ones to possess their Private keys

• Keep in mind very few systems are 100% Asymmetric

• The vast majority of PKI (public key infrastructure) ecosystems use a combination of both
• Asymmetric encryption literally takes a thousand times longer than symmetric encryption

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 18
 When to use Encryption
Encryption is optional – Ask yourself “Is the payload valuable?”

• Of the CIA triad, Confidentiality is the only one considered optional

• Authentication and Integrity are not optional

• If we can be assured a message has both authenticity and integrity that’s enough
for more than half of all security use-cases
• We use confidentiality (encryption) only if the message itself has value

• Encryption is often misused in place of authentication and integrity

• The thought is: If the recipient can decrypt the message, the message must be genuine – NO!
• There are many ways for a symmetric session key to be compromised
• Without authentication, there is no way to really know if any message is genuine

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 19
 Where to use encryption - when needed
Encryption is needed only when the data is valuable in some way
Potential Places
Layers for Encryption

Application
• When needed, it should be implemented it everywhere
Application possible
TLS
• Whatever level you encrypt only protects that layer and lower
Transport
• Most attacks are on the application layer, including most
malware and advanced persistent threat (APT) attacks
Network / IP IPsec (VPN) • Security in the application layer is, by far, the most effective to these
serious threats. TLS, VPN, and lower level encryptions connect defend
data in the application layer
Network
• Ironically, these lower layer encryptions are the most used
Link Encryption
Access
forms today, meaning few are protecting themselves against
the most serious threats they face
Full Disk
Encryption (FDE)
Mass Storage
Transparent Data
Encryption (TDE)

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 20
 Back to defense in depth:
The Three “Vital 3”
• The application of security schemes are layered

• The “Vital 3” of Hardware Requirements to enable security

• The “Vital 3” of Cryptographic Functions all secure systems implement

• The “Vital 3” of Connection Requirements between nodes

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 21
 Defense in depth: The Three “Vital 3”

• The application of security schemes are layered

• The “Vital 3” of Hardware Requirements to enable security

• High-Entropy Random Number Generator
• Hardware-Enforced Persistent-Secure Protected Environment
• An Immutable Portion of Application Code

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 22
 Uses for Random #s in Cryptography
High-Entropy Random Number Generator
• Keys and Challenges
• Random number generation is used to create unguessable symmetric keys
• Random numbers are used to derive new unique keys from symmetric keys
• They are also used as the foundation for the private key in PKI
• The public key is calculated from the private key
• During authentication, random numbers are used as challenges to prove identity

• Initialization vectors and Nonce (numbers used once) for communications are typically
random numbers
• A good example of this would be the cipher mode AES-CBC, where both a session key and IV
are needed.

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 23
 High-Entropy
Random Number Generator (RNG)
• Needed for the Generation of Unique and/or Random Numbers
• Uses a high entropy noise source feeding a deterministic RNG and a “whitening” function.
• Depends on unpredictable quantum variations in the operation of very small devices.
• Must pass the “Next Bit Test”

• Watch out for RNG Charlatans

• Some companies misrepresent their product
• Some overstate the “quantum” noise source for their RNG. Quantum noise sources are commonplace
• These charlatans suggest their noise source is somehow “quantum computing safe”. It’s not!

• Some companies completely misrepresent reality

• Some claim they can extract entropy from embedded systems to create crypto-class RNGs
• Yes! That’s real! High entropy CAN be derived from low entropy sources, but a lot of TIME is
needed
• Since most systems authenticate very quickly after being turned on, there is not enough TIME

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 24
 We should mention
Physically Unclonable Functions (PUFs)
PUF is a mechanism to generate a stable unique number used for identity
• PUF is based on process variations
 Each of these die will receive near identical process treatment
 How much variation do we actually have? …2128? …2127? Or is it more like 264 or
less (insecure)?
 Nobody knows – This is not a quantified value for semiconductor processing

 This is one reason NIST refuses certification for PUF based identity

• What about the stability of the PUF result?

• Two of the most recent “bright shiny objects” in security are “PUF” and “SRAM imprinting”
• These are mutually exclusive – we can’t have it both ways, so…
• A dedicated section of silicon is needed for thousands of SRAM cells and related PUF circuitry = extra cost
• Any number(s) used for identity requires a secure boundary, further increasing cost

• The need for random numbers doesn’t go away

• What about challenges, derived session keys, signatures, etc…?
• If we still need to use RNGs, why not simply use them to create identity to begin with?
• …and in doing so, creating a system which, at least, attempts to follow NIST guidelines

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 25
 More on PUFs
There are usually 2 reasons given to consider PUF

1) Intrinsic Security of the PUF number:

• Since there is no key when unpowered, there is nothing to physically recover from NVM
• This doesn’t mean the key is not leaked by the system when there IS power
• e.g. glitch, fault injection, PA/DPA attacks, micro-probing functions using the number, etc…

2) Simplification of Key Generation:

• The device will create its own private key at power-on. No need to inject anything or embed an RNG

• “No need to inject”? - a private key has no value by itself and is only useful with a certificate endorsing the
corresponding public key. This requires an injected certificate and its signature to be strictly immutable.

• “No need for an RNG”? - if you need to authenticate anything, how is that done without an RNG?
• If only used as a serial number, indeed – nothing needs to be injected,
 But there are FAR cheaper ways of providing unique serial numbers

 PUF requires dedicated silicon real estate AND requires a license fee

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 26
 Hardware-Enforced Persistent-Secure
Protected Environment
Hardware-Enforced Persistent-Secure Protected Environment

• It is commonly known that most software-based solutions can be easily bypassed

• Adversaries target every level of the system
• Persistent-secure areas are the least vulnerable to attack
• The most effective cybersecurity solutions are built on a foundation of persistent-secure hardware

• We provide this level of protection in a many of our devices:

• Secure elements, like Microchip’s CryptoAuthentication Devices
• Secure MCUs, like Microchip’s Cortex M23 TrustZone based ATSAML11
• Secure MPUs, like Microchip’s PCI pre-certified Cortex A5 TrustZone based ATSAMA5D2x
• Secure FPGAs, like Microchip’s FPGAs
• a highly valued product line from the recent acquisition of Microsemi (formerly Actel)

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 27
 An Immutable Portion of
Application Code
• Another “must have” feature to achieve security
• There needs to be a area of code which can be relied upon to be guaranteed genuine
• This area needs to be unchangeable, but not necessarily ROM

Hot air PCB rework station

$108 brand new

• This immutable, guaranteed genuine, area of code will call the cryptographic functions

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 28
 Defense in depth: The Three “Vital 3”

• The application of security features is also layered

• The “Vital 3” of Hardware Requirements to enable security

• The “Vital 3” of Cryptographic Functions all secure systems implement
• Secure Boot
• Secure Image Updates
• Authenticated and Unique Messaging

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 29
 Secure Boot
Secure Boot is one form of Attestation

• Secure boot assures only genuine image boots the device

• The code is from the OEM or an OEM-approved source… and no other

• Requires an immutable boot area

• This area does not need to be ROM, but it shouldn’t be changeable with anything short of a full
chip erase.

• Can be accomplished both Symmetrically and Asymmetrically

• Symmetrical Secure Boot would use a MAC of the application image using a parent key
• Asymmetric Secure Boot and uses a signature of the digest of an application image

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 30
 Asymmetric Secure Boot Sequence
Using Signature verification for code authentication

We start in this condition

(How we get here is either from the initial factory load or via
Secure Firmware Update (Secure DFU)

Vulnerable area Persistent-Secure area The securely stored

A digest of the AI Signature
OEM public key is
application is generated used to verify the
Application
Image (AI)
* signature
Hash OEM

Boot Loader
KPUB • Public keys are not
AI
Digest secret, but the OEM
public key needs to
Verify be secured and
The AI Digest and the therefore trusted.
AI Signature (signed • If an adversary were
by OEM private key) able to plant their
are sent into the public key here, they
secure area would have hijacked
An immutable boot loader must drive this your device

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 31
 Secure Image Updates
Secure updates are another form of attestation

• Secure update assures only genuine images are accepted by the device
• The code is from the OEM or an OEM-approved source… and no other

• Requires an immutable boot area

• This area does not need to be ROM, but it shouldn’t be changeable with anything short of a full
chip erase.

• Can be accomplished both Symmetrically and Asymmetrically

• Symmetrical Secure Boot would use a MAC of the application image using a parent key
• Asymmetric Secure Boot and uses a signature of the digest of an application image

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 32
 Asymmetric Secure DFU Sequence
Using Signature verification for newly received code authentication
Installed System

Payload System memory

New
Firmware
Application
Code
Image (AI) Persistent-secure
area
AI Signature

ECDSA Firmware SHA256

Verify Digest HASH
From
OEM Reject Code
S/W Dev Auth
KPUB KPUB
Accept New Code
ECDSA
Verify
Auth
Certificate

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 33
 More on Secure Boot and Secure
Image Updates

• These topics are another class unto themselves

• We highly recommend our lecture dedicated to this subject:

• “How to do Secure Boot & Secure Image Upgrades”

• … learn about secure boot and secure image upgrades are empowered
using cryptographic functions… …for microcontrollers, microprocessors,
FPGAs, and automotive applications…
– Microchip Masters Class

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 34
 Authenticated and Unique Messaging
• Authentication and Integrity must be established between communicators
• Entities should authenticate upon initial contact with other entities
• All messaging and data transfers should be authenticated

• All messages should be made unique to thwart “replay” attacks

• Replay attacks are incredibly easy and very common

• There are many solutions to accomplish message uniqueness

• Many require specialized functions, memory, and/or synchronization
• Counters, time-stamps, etc…

• Here’s an easy 2-step solution requiring very little memory and no synchronization
1. Ask the other side for a nonce before compiling a message payload
2. This ephemeral number will be used by both sides in the authentication of the message

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 35
 Symmetric Message Uniqueness
Bob wants authentication of a message from Alice
Alice & Bob know and trust each other and share a secret key

Alice Bob

Alice requests a nonce for

her next transmission to Bob 01100…111011
Bob creates a random #

MAC Function MAC Function

Shared Key
Shared Key

CheckMAC
MAC Alice now has information
she can use to make her
message unique
© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 36
 Symmetric Message Uniqueness
Bob wants authentication of a message from Alice
Alice & Bob know and trust each other and share a secret key

Alice Bob
Alice generates a message
and random# Bob stores the
message

Random #
MAC Function Bob sent MAC Function
Shared Key Shared Key Message
Uniqueness
is achieved
CheckMAC
No long-term
memory required
MAC

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 37
 Encrypt or not, we still need to
authenticate
Let’s talk about proper hashing. Admittedly, this is an oversimplification
State21 State0
Initialization
• Hash is a “Compression Function”
• A one-way function that transforms two fixed-length inputs
into one output of the same fixed-length
Compression
Function

State3 • The transformation is "one-way", meaning it is infeasible -

Digest given a particular output - to compute inputs which
Message01

compress to that output

• CRC is a hash everyone knows about, but it’s not strong

enough for cryptography

• When using a crypto-hash, like SHA2, it is infeasible for two

Simple MAC Function files to produce the same hash digest

Message0 = “The money transfer was received.”

Message1 = “Many thanks for your effort!”

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 38
 “Length Extension Attack” on simple
MACs
More oversimplification. Msg length, padding, etc… all need to be considered.
BWAH HA StateHA
4 StateHA!!!
Digest
Initialization 0

Compression
Compression

Function
Function

State3 State5
Digest New “Authentic” Digest

Message23
Simple MAC Function Same MAC Function
Message0 = “The money transfer was received.” Message0 = “The money transfer was received.”
Message1 = “Many thanks for your effort!” Message1 = “Many thanks for your effort!”
Message2 = “Please send the same amount again.”
Message3 = “This time to Joe Schmoe in Idaho.”

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 39
 HMAC and CMAC are not susceptible to
Length Extension Attacks
• HMAC – Hash-based Message Authentication Code
• Lots of confusion – “Isn’t a simple MAC also hash-based?” Yes, but…
• Uses two passes of hash computation
• The secret key is first used to derive two keys – inner and outer
• The first pass of the algorithm produces an internal hash derived from the message and the
inner key
• The second pass produces the final HMAC code derived from the inner hash result and the
outer key
• The algorithm thwarts Length Extension Attacks

• CMAC – Cipher-based Message Authentication Code

• Block-cipher based algorithm which provides both assurance of authenticity and integrity of data
• Key is used on every new block so this too thwarts length extension attempts

• And, of course, digital signatures protect against this attack as well

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 40
 Asymmetric Message Uniqueness
Bob wants authentication of a message from Alice
Alice & Bob know and trust each other and have their own public/private key pairs

Alice Bob

Alice requests a nonce for

her next transmission to Bob 01100…111011
Bob creates a random #

Sign
Bob Bob’s
KPRIV Private Key

Verify
Digital Alice now has information
Bob Bob’s Signature she can use to make her
KPUB Public Key
message unique

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 41
 Asymmetric Message Uniqueness
Alice wants to send a message to Bob
Alice & Bob know and trust each other and have their own public/private key pairs

Alice Bob
Bob stores the
message

Alice Generates a Message

Random #
HASH HASH
Bob sent

Digital Alice’s
Alice’s Sign Verify
Signature Public Key
Private Key Alice
KPRIV Alice
KPUB

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 42
 Defense in depth: The Three “Vital 3”

• The application of security features is also layered

• The “Vital 3” of Hardware Requirements to enable security
• The “Vital 3” of Cryptographic Functions all secure systems implement
• The “Vital 3” of Connection Requirements between nodes
• Identification
• Authentication
• Authorization

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 43
 Identification ≠ Authentication ≠ Authorization
Three required elements of any secure connection are often confused with each other

• Identification – A claim to be something or someone

• For embedded devices, this could be a unique serial number and device type
• For websites this could be a user name

• Authentication – The act of proving an identity claim

• For embedded devices this could take the form of a random challenge and appropriate
response
• For website access this could be providing a secret password

• Authorization – Once identified and authenticated, the device or person is authorized

to access system and/or data
• That authorization should be limited to only those resources required by the user

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 44
 Review of the Three “Vital 3”
• The “Vital 3” of Hardware Requirements
• High-Entropy Random Number Generator
• Hardware-Enforced Persistent-Secure Protected Environment
• An Immutable Portion of Application Code
• The “Vital 3” of Cryptographic Functions
• Secure Boot
• Secure Image Updates
• Authenticated and Unique Messaging
• The “Vital 3” of Connection Requirements
• Identification
• Authentication
• Authorization

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 45
 Address other common vulnerabilities
This is more for advanced systems

• Consider running a secure kernel (e.g. TrustZone or seL4) or other

hypervisor/gate-keeper function to authenticate communications coming into
trusted space from external sources
• Remember “Identify, Authenticate, Authorize”
• Provide only those privileges needed and no more
• Wireless and wired
• Removable media like a USB thumb drive

• Have you considered testing hardware delivered by your suppliers before

installing it!?
• Supply chain attacks are real - Just saying ☺
• Add a security sweep to your incoming tests

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 46
 Use-Case Example
Symmetric Cryptography
Captive Network – One OEM, no interoperability

P2P Star
Mesh Radio

MCU/MPU
Sensors
and/or
Secure Enclave or
Relays Element

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 47
 This is a generic network
But, for a moment, let’s think of it as an access control network to a building
• Ecosystem considerations for the access control use case
• Who will have access? Why do they need access? Where will they have access?
• During what times will they have access? Who can grant access? Etc…

• Each homeowner / building-owner will have an account from a cloud provider

• Each property will have its own sub-account with knowledge of the locks on that property
• Any user can exist in multiple sub-accounts
• Allows “master key” functionality between properties

• Three classes of users

• Master users – Full access and privileges in the account – “master key” privileges
• Account is fully accessible through their computer or phone
• Resident users – semi-permanent privileges limited to unlocking the door
• No account access - Permissions are either subscription or permanent (requiring revocation)
• Guest users – Short-lived privileges limited to unlocking the door
• Permissions have short validity - Permissions are one-time or subscription
• e.g. A maid has subscription access to a home on Tuesdays from 2PM to 4PM

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 48
 Thinking security from the beginning
Applying the three “Vital 3” to every design from the start
• The “Vital 3” of Hardware Requirements
✓ High-Entropy Random Number Generator
✓ Hardware-Enforced Persistent-Secure Protected Environment
✓ An Immutable Portion of Application Code

• The “Vital 3” of Cryptographic Functions

✓ Secure Boot
✓ Secure Image Updates
✓ Authenticated and Unique Messaging

• The “Vital 3” of Connection Requirements

✓ Identification
✓ Authentication
✓ Authorization
© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 49
 Assure the ecosystem remains secure
Limit the scope of any successful hack as much as possible

• Symmetric cryptography implies all devices is use a shared key

• That also means if the key is revealed the entire ecosystem, every installation, is compromised
• The architecture of the ecosystem is as important as the cryptography used

• Devices can be authenticated with an ecosystem-wide Parent key

• Distribution of this key should be strictly controlled
• The parent key should be protected in a hardware-enforced persistent-secure enclave
• The parent key will never come out and only be used inside this secure enclave

• The Parent key is only used for system setup and never used directly
• Each device will have a unique key derived from the Parent key
• Very few devices will actually contain the parent key

• Let’s see how we can construct a robust ecosystem with animated graphics
© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 50
 How we Provision in the Factory
How nodes and Network coordinators are prepared in the factory

Parent Key
From HQ
Hardware
Security
Module
Node
Secure area
Manufacturing
Line HASH Unique SN#
Parent
Key

Unique
Derived Device Key
Secure area

Network Coordinator
Parent
or
Key
Installation Tool

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 51
 The Auth Process during installation
The Network Coordinator wants assurance the Node is genuine
Network Coordinator Node

Recreate the unique

Secure area Secure Area

derived key for

disposable
Parent
Key Unique SN#
HASH

Derived Device Key

Derived Device Key
Generate random
challenge

Random
HASH RNG HASH
Challenge

Digest

Digest
Calculate genuine

=?
response and
compare

RNG = Random Number Generator

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 52
 Sharing a unique key during installation
Assures each installed network has a unique key so one compromised network will not compromise others
This is performed with each node until the entire network has the key

Network Coordinator Node

Network Coordinator 01100…111011
spawns a random Random Seed 01100…111011
number to be used as
the network key
Crypto Hash Crypto Hash
Derived Device Key Derived Device Key

Session Key
New Unique Network Key New Unique Network Key

Cipher Cipher
Cipher Text
(Encrypt) (Decrypt)

If the network does not support a cipher, XOR can be used

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 54
 The network key must remain secure
The common network key is never used directly
Session keys are generated from random seeds from the Network Coordinator

Network Coordinator Nodes

01100…111011
Random Seed 01100…111011
Network Key Network Key

Crypto Hash Crypto Hash

Derived Session Key

Cipher Cipher
Plain Text Cipher Text Plain Text
(Encrypt) (Decrypt)

Encryption of messages is optional – Only encrypt if payload is valuable

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 55
 What if the network wasn’t private / enclosed?
Other vendor’s equipment needed to interoperate

• If the network needed to support more than one vendor’s equipment, PKI
certificates are used to allow interoperability with other vendor’s equipment
• Easy to do… just share the authority public keys for all participating vendors
• Allows multiple chains of trust to be supported

• Authentication would occur normally under PKI rules

• Subject public keys would be verified using chain of trust certificates

• Network key exchange would also follow PKI rules

• Spawn session keys from a Diffie-Hellman operation
• Let’s review that quickly with an animated slide

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 56
 How to distribute a common network key with PKI
This is performed with each node until the entire network has the key
Network Coordinator Node
Private Key Public Key Public Key Private Key

Public Key Exchange

Diffie-Hellman Computation Diffie-Hellman Computation

Shared Secret
(Pre-Master Secret)

Session Key

Network Key Network Key

“Rinse and Repeat”

XOR or XOR or with every node in
encrypt Blinded Key decrypt the network

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 57
 OEM Specific Intermediate Certificate Authorities
CA = Certificate Authority

• The Root Certificate Autority Root CA Root of Trust

• Creates one or more intermediate CAs

• The intermediate CAs are the “working CAs” OEM specific

Intermediate
• Protects the Root of Trust in case a “limb of the tree” is OEM
OEM Certificate Authorities
compromised and needs to be pruned OEM
• Creates the OEM Specific Certificates which assures the
world the CM is genuine OEM Specific
• These authenticated key pairs are distributed among the Certificate(s)
entities which need authority
• Manufacturing to create new devices
• S/W dev team to sign/send code updates/upgrades
• Licensed partners to create product Massively Parallel Production:
• Anyone the OEM wants to grant authentication privileges to Generate and Sign individual Device
Certificates

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 58
 Did we meet our objectives?

• Developing a Security Thought Process

• Key Management
• When to use Symmetric vs Asymmetric Cryptography
• When to use Encryption
• The Three “Vital 3”
• The “Vital 3” of Hardware Requirements
• The “Vital 3” of Cryptographic Functions
• The “Vital 3” for all Connections
• Use-Case example
• Networks
• Specifically, an Access Control network

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 59
© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 60
 Legal Notice
SOFTWARE:
You may use Microchip software exclusively with Microchip products. Further, use of Microchip software is subject to the copyright notices, disclaimers, and any license terms
accompanying such software, whether set forth at the install of each program or posted in a header or text file.

Notwithstanding the above, certain components of software offered by Microchip and 3rd parties may be covered by “open source” software licenses – which include licenses that require that
the distributor make the software available in source code format. To the extent required by such open source software licenses, the terms of such license will govern.

NOTICE & DISCLAIMER:

These materials and accompanying information (including, for example, any software, and references to 3 rd party companies and 3rd party websites) are for informational purposes only and
provided “AS IS.” Microchip assumes no responsibility for statements made by 3rd party companies, or materials or information that such 3rd parties may provide.

MICROCHIP DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING ANY IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY, AND
FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL MICROCHIP BE LIABLE FOR ANY DIRECT OR INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, OR CONSEQUENTIAL LOSS,
DAMAGE, COST, OR EXPENSE OF ANY KIND RELATED TO THESE MATERIALS OR ACCOMPANYING INFORMATION PROVIDED TO YOU BY MICROCHIP OR OTHER THIRD PARTIES, EVEN IF
MICROCHIP HAS BEEN ADVISED OF THE POSSIBLITY OF SUCH DAMAGES OR THE DAMAGES ARE FORESEEABLE. PLEASE BE AWARE THAT IMPLEMENTATION OF INTELLECTUAL
PROPERTY PRESENTED HERE MAY REQUIRE A LICENSE FROM THIRD PARTIES.

TRADEMARKS:
The Microchip name and logo, the Microchip logo, Adaptec, AnyRate, AVR, AVR logo, AVR Freaks, BesTime, BitCloud, chipKIT, chipKIT logo, CryptoMemory, CryptoRF, dsPIC, FlashFlex,
flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, Microsemi logo, MOST, MOST logo, MPLAB, OptoLyzer,
PackeTime, PIC, picoPower, PICSTART, PIC32 logo, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom, SyncServer, Tachyon,
TempTrackr, TimeSource, tinyAVR, UNI/O, Vectron, and XMEGA are registered trademarks of Microchip Technology Incorporated in the U.S.A. and other countries.
APT, ClockWorks, The Embedded Control Solutions Company, EtherSynch, FlashTec, Hyper Speed Control, HyperLight Load, IntelliMOS, Libero, motorBench, mTouch, Powermite 3,
Precision Edge, ProASIC, ProASIC Plus, ProASIC Plus logo, Quiet-Wire, SmartFusion, SyncWorld, Temux, TimeCesium, TimeHub, TimePictra, TimeProvider, Vite, WinPath, and ZL are
registered trademarks of Microchip Technology Incorporated in the U.S.A.
Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, BlueSky, BodyCom, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion,
CryptoController, dsPICDEM, dsPICDEM.net, Dynamic Average Matching, DAM, ECAN, EtherGREEN, In-Circuit Serial Programming, ICSP, INICnet, Inter-Chip Connectivity, JitterBlocker,
KleerNet, KleerNet logo, memBrain, Mindi, MiWi, MPASM, MPF, MPLAB Certified logo, MPLIB, MPLINK, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM, PICDEM.net, PICkit,
PICtail, PowerSmart, PureSilicon, QMatrix, REAL ICE, Ripple Blocker, SAM-ICE, Serial Quad I/O, SMART-I.S., SQI, SuperSwitcher, SuperSwitcher II, Total Endurance, TSHARC, USBCheck,
VariSense, ViewSpan, WiperLock, Wireless DNA, and ZENA are trademarks of Microchip Technology Incorporated in the U.S.A. and other countries.
SQTP is a service mark of Microchip Technology Incorporated in the U.S.A.
The Adaptec logo, Frequency on Demand, Silicon Storage Technology, and Symmcom are registered trademarks of Microchip Technology Inc. in other countries.
GestIC is a registered trademark of Microchip Technology Germany II GmbH & Co. KG, a subsidiary of Microchip Technology Inc., in other countries.
All other trademarks mentioned herein are property of their respective companies.
© 2019, Microchip Technology Incorporated, All Rights Reserved.

© 2019 Microchip Technology Incorporated. All Rights Reserved. 23064 SEC2 Slide 61