Security in Everywhere ARM Tech Symposia 2016 David Kuo ......SSL MACsec IPSec SSL/TLS Description Layer 2 security Hop-by-hop Peer-to-peer protocol Layer 3 ”network layer” security

Security in Everywhere

ARM Tech Symposia 2016

David Kuo

[email protected]

October 2016

Security Basic Concepts

| 2016 ARM Symposia3

Security must be sized relatively to the environment

where the device is running and its accessibility to the hacker

Security Basic Concepts

@ System Level

Software attacks: protocols,

weak implementation of

cryptography, weak passwords,

malware, viruses, Trojan

horses, …

@Board (Device) Level

Software attacks + non

invasive HW attacks

through Debug Port,

Memory Access, Power

Analysis, …

@ Chip Level

Software Attacks +

Physical Invasive HW

attacks: Laser, FIB,

Reverse Engineering,

Probing, …

Cost of the attack

Device Accessibility


Security implementations Must be sized relatively to the consequence of a hack,

Not to the value of the device.

The hacker will put in perspective: The “value” of the hack:

- E.g. money, fun, technical challenge, terrorism…

The “cost” versus the “risk” of the attack:

- Time spent to perform the attack,

- Expertise required to perform the attack,

- Level of collusion (level of information of the system),

- Cost of equipment needed to perform the attack (the economical barrier),

- Access to the system (physical access, protected by firewall…),

- Legal penalty if caught (fine, prison…),

Example: the Smart Meter gateway: Bill of Material: <$20,

Consequence of an attack: black-out in neighborhood: $Millions.

Cost of implementation of Security

?


Security for TV/STB/OTT/


HD Content Protection

Television, Monitor, Projector

Internet

Digital Rights Management

Laptop

PC

Notebook

Tablet

Smart Phone

Set-Top Box/ OTT

• Wired / Wireless Conn.

• HDMI/DisplayPort/Miracast/DLNA

• IP-Based

• Higher-level Content Protection

•HDCP2.0/2.1/2.2

• DTCP–IP

Assets

Rich Content

(U)HD Content

Protection


Security for Banking Application

| 2016 ARM Symposia8|

蠶食鯨吞 ---第三方支付深入你的食衣住行3rd party payment penetrate in deep in daily life and erode traditional banking business.


傳統金控面對來勢洶洶的第三方支付大舉壓境之時 ( Facing the

upcoming competition from 3rd party payment among the traditional

banking industry : )

發展行動支付勢在必行 ( Developing mobile payment is a must )

過去以個人電腦為服務拓展核心 ( Transition from PC centric )

現在以無所不在的移動平台App為服務發展觸角 ( into app based

mobile platform everywhere )

客戶隱私保護與數據傳輸安全的保障為廣泛採用之最後一哩路 (

account confidential and privacy data protection and ensuring the

secure data transmission become the last mile before such mobile

service is persuasively adopted )

Now or never 刻不容緩


Bad app is everywhere…( 250 apps

were withdrawn from apple App

store….)

Are you sure that your ID/PW are secure when it is

in use or at rest? ( Hollywood Stars’ Photo/Video

exposure…)


Every software application is vulnerable to binary hacking

Networks are transparent

Intended operation is easily subverted

Security systems are undermined

License checks are removed

Apps are repurposed as attack vectors

Keygens are created

HostIDs and clocks are spoofed

Clients and servers are compromised and cloned

Embedded software is stolen

CE IP is subverted

Unprotected Software is Easily Hacked


既然無法兼善天下(OS) ( Since there is no way for you to enforce the enhancement of security

from OS side….)

但求獨善其身(APP) ( the alternative way is to ensure your developed App can be tampered

resistant via: )

受入侵時提供警示 ( auto alert while there is attempt of tampering )

讓入侵者不得其門而入 ( make the door to secret invisible )

保護證書密鑰用於無形 ( protect the certificated and secret key from being probed and replaced

and use it in a invisible way )

Wrapper/Sandbox cannot protect the app from being tampered during runtime.

安全的道路上你需要專家的協助 ( you need expert’s

assistance on road of security )


WhiteBox Technology白箱技術

Cryptographic

Algorithm Input: ABC

Key: 1234

Output: XYZ

WhiteBoxInput: ABC Output: XYZ

Before

After


Security for Communication


Security Challenges in the NetworkSolution: Strong encryption, authentication, and platform integrity

2-WayCommunication

2-WayCommunication

Server

Data Management

Take control of the Device

or Application

Insert Non-Authorized Devices

Man in The Middle: (Are we talking to the expected endpoint?)• Spy the line

• Hijack network

• Replay

• Broadcast private information

Take Control of the

Routers/Servers

Gateways /

Router

Rogue or

Personal

Devices


Mass adoption of standards based security protocols SSL/TLS (Device/Server), IPsec (Client/Server), MACsec (Device)

Wireless – Zigbee, WPA, CAPWAP, LTE/3G Baseband,

Platform – Data Storage, Asset Protection

Data plane performance continues to increase: Today: Stalled at 10Gbps due to protocol and implementation limitations

L2: MACsec, beyond 100Gbps, multiport 40G, line speeds

L3: IPsec, 40Gbps and higher,

L4: SSL/TLS/DTLS, 40Gbps and higher

Control plane secure tunnel establishment & key management: Key refresh and tunnel setup rates matching 40Gbps and beyond

Efficient , area optimized Public Key Accelerators & True Random Number Generators needed

Platform (intrinsic) security At a minimum: Secure Boot and Secure Debug

Better: Trusted Execution Environment, Trust Anchor, Key Vault

Security Requirements for Connected SystemsFrom Core to Cloud


Comparison: MACsec to IPSec to

SSL

MACsec IPSec SSL/TLS

Description Layer 2 security

Hop-by-hop

Peer-to-peer protocol

Layer 3 ”network layer”

security

End-to-End ”tunnels”

Peer-to-peer Protocol

”Secure Sockets” ie

application layer

encryption;

Client-server model

Complexity

Deployment

Relatively simple to

implement

Phased deployment

possible

Complex protocol suite,

many options

Key management and

distribution with another

(complex) protocol (IKE)

Security to be built-in

to the application

Tunnel use with

limitations

Phased deployment

difficult

Performance Designed for very high

speeds (> 40 Gbps)

Assumes HW crypto in

most cases

Ranges from low to high

(Embedded Clients to

Telco Switches)

HW crypto use prevalent

Assumes medium to

low performance

HW assist possible at

server end


Security Protocols: Which security protocol will each application use?

- Examples: IPsec (gateway/gateway), SSL/TLS (client/server), DTLS (client/server) for SSL VPNs,

VoIP, and CAPWAP for Wireless AP Provisioning, MACsec (Ethernet)

Performance: What is the network bandwidth of the device? Do you require line rate security performance?

CPU Utilization: How compute intensive is the protocol implementation?

- What is your power budget? (Battery, AC powered?)

- How many CPU cycles are available for security?

(Is this a forwarding device or is data initiated/terminated by apps on the local CPUs)

Application Concurrency Will multiple applications in the system all require security services?

Is there a requirement to isolate crypto keys & operations from other applications running in the system?

Is there a trusted execution environment present such as ARM TrustZone?

The solution to all these questions is a dedicated HW resource to accelerate all crypto functions

System considerations when selecting a security architecture


System tradeoffs for each architecture

HW Crypto

Accelerator

Security Data plane

Stacks

Packet EngineSecurity Data plane

Stacks

Security Data plane

Stacks

Security Control plane



Packet Engine & Classifier

Security Data plane

Stacks (incl SW crypto)

Security Control plane#1 & #2

SW only Security

Protocol

SW complexity

PerformanceHost utilization

low high

Power dissipation

SW complexity


low high

Power dissipation

SW complexity


low high

Power dissipation

SW complexity


low high

Power dissipation

#4 Using a HW

Crypto Packet

Engine

#3 Using HW

AES & HASH

cores

#5 HW Security

Packet Engine /w

classifier

Mo

re E

ne

rgy &

Pe

rform

an

ce E

fficie

nc

yMost Efficient and Scalable

Architecture


Security Acceleration is not efficient by only accelerating the actual cryptographic tasks.

Crypto acceleration only has effect for large packets.

IPsec Security and Crypto ProcessingWhere to Optimize and Accelerate?

IPsec tasks

on host

Crypto tasks

in SW or in HW

Application

flow id

calculation

send data

SA

lookup

packet

trans-

formation

content encryption

packet

routing

init and

call

crypto HW

hash

init and

call

crypto HW

wait

do other tasks do other tasks

interrupt interrupt

Processing time depends on packet size

Processing time independent on packet size,

fixed per packet, large overhead for small packets

In

cre

asin

g T

hro

ug

hp

ut

Increasing Packet Size

Throughput dominated by packet

processing overhead

Throughput dominated by data

bandwidth limits

A

B

c


HTTP file download over an IPsec VPN tunnel

Example: 500MB binary file download

1400-byte IP packets using TCP via HTTP at 60Mbps

The packet engine significantly reduces power consumption.

INSIDE’s EIP-197 Packet EnginePower Example Explained

The Packet Engine is 10x greater in energy efficiency for the

same operation when compared to software only

File download @60Mbps No Security SW SecurityARMv8

HW Security w/EIP-197

CPU Type (big or little) Little Big Little

CPU Frequency 300MHz 1600MHz 600MHz

CPU Load 10% 75% 50%

CPU Power 30mW 1200mW 110mW


Efficient Driver Development Kits on EIP-197

Seamless Integration with INSIDE’s QuickSec & Matrix SW stacks

Open Source Stacks (which still lack efficient use of HW resources)

Support ARMv7 & ARMv8

INSIDE Secure Offers: QuickSec MACsec Toolkit

QuickSec IPsec Toolkit

MatrixSSL SSL/TLS/DTLS Toolkit

Demonstrated real life 40Gbps performance on customer silicon with INSIDE Secure packet engines

Alternative Protocols for Deployment Flexibility LTE/3G/2G crypto as an option: KASUMI f8-9/SNOW 3G/ZUC

Storage crypto support as an option: XTS-AES

DTLS CAPWAP for managing large WiFi deployments

Protocol processing Software toolkitsRequired in addition to the Hardware Implementation


Manufacturers are liable when hacks succeed

Power efficiency lowers cost & increases MTBF

High speed network systems continue to drive best profits

Why choose inside secure

INSIDE Secure has a complete suite of HW-IP for all your design points, with the available protocol

source code for a complete system implementation

Protocols

Performance

Power

Risk

SSL/TLS, DTLS, IPSec, MacSec,

VPN’s, HDCP, DTCP

Hardware acceleration enables the

fastest systems

Hardware acceleration decreases

power

Effective security keeps your

company out of the news

Security already pervasive and required

Secure Communication for

Data Center Chip


Network security threats expand daily

Consultants, contractors and even guests have network access.

Unmanaged devices come into the workplace, attaching to networks.

Many people have ability to access secured networks, that are internally handling traffic from many authorities

within the network.

Threats Include:

MAC address spoofing used to gain unauthorized access to a network or to services from an ISP or to mask

identity during illegal activity.

Passive monitoring or ‘eavesdropping’ from Ethernet line or other transport networks, to obtain sensitive

information such as passwords or proprietary company data.

Man-in-the-Middle attack where an attacker operates between a client and server, to either intercept sensitive

data or to modify that data as it is being transmitted.

Ethernet Security Threats


Secure Ethernet communications are essential

Government agencies around the world have set demanding certification standards for encrypting sensitive transmitted data.

Commercial organizations adopt encryption as the optimal approach to protecting sensitive data transmitted across their Wide and Metropolitan Area Networks that interconnect their different sites.

Achieved with encrypting and integrity protecting end-to-end data traffic

Based on cryptographic keys, algorithms and management policies

Further Security Requirements

High-performance – ideally at maximum capacity of the network.

Low and predictable latency for all deployments

‘IT friendly’

- Scalable

- Runs across multiple devices

- Works seamlessly with other types of network protection devices, such Intrusion Detection/Prevention Systems via deep packet inspection.

Market requirements for Security


Using IPsec or SSL/TLS is not scalable to Secure the LAN

End-to-End security example:

Securing all data between

user PC’s and network

servers/printers using IPSec

Configuration complexity:

With:- X clients and,

- Y servers,

- X*Y tunnels to manage.

In this example:- 20 tunnels so,

- 40 session keys.

Server load

Each server has to encrypt and decrypt data for X tunnels: not scalable!


MACsec Deployment Scenario:Hop-by-Hop

MACsec requires 1 Connection Association

per collision domain:

In this example

7 CA’s.

Number of active keys in a CA equals

the number of CA participants:

So in total

18 keys here.

Computational load distributed

over switches / routers:

Scalable

Different from 802.1X:

MACsec allows multiple authenticated and secured clients per port

hub MACsec capable

switch or router

MACsec Enabled


Today, networks are secured mostly with end-to-end VPN (Virtual Private Network):

Layer 3 protocol (IPsec).

Application layer protocols (SSL/TLS).

Due to complexity and place in the network stack these are typically running on application processors

Acceptable for relatively slow Client connection (e.g. accessing Bank or Emails).

Too slow and too expensive for network infrastructure.

Hardware acceleration is costly and complex

Industry is moving towards integrating security into the Network equipment.

Maximize efficiency by implementing protection in hardware.

Throughput scaling along with evolution of the Network equipment.

The MACsec security standard (IEEE 802.1AE and IEEE 802.1X) was designed specifically to provide port based security across Local Area Networks (LANs).

What is MACsec and why is should be used


The MACsec security standard was specifically designed to secure ‘hop-by-hop’ network connections requiring every port at the end of an Ethernet segment to be MACseccompliant.

To provide end-to-end WAN security, many vendors adopted MACsec to be used across the following use case:

Core networks

Provider Edge network

Virtual LAN Connections between Campus and Branches

Data center interconnects

This brought the following requirements to MACsec implementation:

Suitable for integration into the network port. Typically MACsec is placed into the Ethernet or Optical Transport Network PHY

- This allows adding MACsec by upgrading line cards and not changing other parts of the complex equipment.

Throughputs from 10Mbit to 500Gbit

- Low-speed PHYs (up to 10Gbit)

- High-speed Ethernet (10Gbit to 100G bit)

- Multi-mode Ethernet and OTN (10 Gbit to 500 Gbit)

Ability to leave some parts of the packet unprotected to be accessed and modified by the network nodes.

Featured frame classification to support multiple virtual MACsec ports at the same physical port.

MACsec adoption and market requirements


Low latency

Scalable

Many different deployments

High speeds

Mixing various interface speed grades

Line rate processing for all type of packets and all packet sizes

Fixed latency/timing

Evolvement to FlexE

All these items are addressed with INSIDE Secure’s MACsec IP products

INSIDE Secure’s products can be embedded behind the MAC interface. Without applying the security function it is

fully transparent.

General requirements/properties of L2 networks


Example: MACsec in Data Center Interconnects

MACsec enabled router


Example: MACsec through access provider’s

network


MACsec in Typical Router/Switch

design

The MAC is the ‘natural’ place for MACsec.

But there are benefits to implement MACsec in PHY (e.g. Vitesse)

Switch ASICControl Processor

up

link

PHY

PHY

PHY

PHY

XAUI, or PCIe,

hypertransport,

...

XA

UI

GM

II, RG

MII

10G PHY module

(XENPAK, SFP+)

1Gbp PHY module

(SFP)

MA

C

MACsec data

plane (802.1ae)

MACsec control

plane (802.1X-REV)

MAC

MACsec data

plane (802.1ae)


Why MACsec in the PHY?

• The Ethernet MAC is often located inside the switch ASIC, with the

PHY parts as separate components or pluggable modules

• Thus, putting MACsec in a router requires replacement of the switch

ASIC

– Switch ASICS only upgraded for significant new functionality – thus

new pinout and new board design

– Customer will have to replace his complete router/Line Card

• Adding MACsec capability to a pluggable module allows an easy

upgrade option

– Router/switch manufacturers can reuse board design if MACsec

capable PHY chips are drop-in replacements

– Customer only replaces modules


IoT

MONETIZING THE INTERNET OF THINGS WITH

INSIDE SECURE

For more information, please feel free to contact InsideSecurevia [email protected]

Documents

Security in Everywhere ARM Tech Symposia 2016 David Kuo ......SSL MACsec IPSec SSL/TLS Description Layer 2 security Hop-by-hop Peer-to-peer protocol Layer 3 ”network layer” security