External Use

TM

Security in Digital Networking 101

FTF-SDS-F0218

A P R . 2 0 1 4

Geoff Waters | Systems Architect

Ravi Malhotra | Software Architect

TM

External Use 1

Agenda

• Security Engines

− Internals – CHAs, DECOs, job submission

− Performance

• Security Enablement

− Drivers and libraries

Bare-metal, Linux® Kernel, User-space

Using a security driver and internals

− Middleware and applications

IPsec - Native Linux IPsec, ASF, VortiQa IPsec

SSL - OpenSSL, VortiQa SSL

TM

External Use 2

Security Engines

TM

External Use 3

Freescale SEC Engine Evolution

MPC180 MPC184

MPC185

MPC190

8272

885

Phase 1

Crypto

Co-Processors

Phase 3

Integrated Security Protocol Engines &

Trust Arch

85xx

SEC 4.x

83xx

81xx

85xx

83xx

81xx

SEC 2.x P4xxx

P3xxx

81xx

P1xxx

P2xxx

P5xxx

P2xxx

P1xxx

Phase 2

Integrated Crypto Acceleration Engines

SEC 5.x

SEC 3.x

SEC 1.x

SEC 6.x

C29x Specialty Co-Processors

T4xxx

B4xxx

T2xxx T1xxx

B913x

LS1xxx

• Phase 1 – PowerQUICC 1 processors

− Freescale Security Technology rolled out to commercial networking market through security

− Co-processor product line

• Phase 2 – PowerQUICC 2, PowerQUICC 2 Pro, PowerQUICC 3 processors

− Integration of security IP into Freescale communications processor products

• Phase 3 – QorIQ processors including P series, T series and LS series of devices

− Continual improvement of baseline IP for integration, addition of Trust Architecture. SEC 5.0 scales to 40 Gbps+. Spin security IP back out into specialized co-processor product line.

TM

External Use 4

SEC 5.0 As featured in QorIQ T4240 processor

(1) Public Key Hardware Accelerator (PKHA) − RSA and Diffie-Hellman (to 4096b) − Elliptic curve cryptography (1024b) − Supports Run Time Equalization

(1) Random Number Generators (RNG4) − NIST Certified

(4) Snow 3G Hardware Accelerators (STHA) (~12Gbps) − Implements Snow 3.0 Keystream Generator − f8 encryption per ETSI/SAGE 128-UEA2 (and 128-EEA1) − f9 authentication per ETSI/SAGE 128-UIA2 (and 128-EIA1)

(4) ZUC Hardware Accelerators (ZHA) (~10Gbps) − Implements ZUC Keystream Generator (per spec v1.5) − Authentication per ETSI/SAGE 128-EIA3 (spec v 1.5) − Encryption per ETSI/SAGE 128-EEA3 (spec v 1.5)

(2) ARC Four Hardware Accelerators (AFHA) − Compatible with RC4 algorithm (~7.5Gbps)

(8) Kasumi F8/F9 Hardware Accelerators (KFHA) − F8 , F9 as required for 3GPP (~20Gbps) − A5/3 for GSM and EDGE, GEA-3 for GPRS

(8) Message Digest Hardware Accelerators (MDHA) − SHA-1, SHA-2 256,384,512-bit digests (~40Gbps) − MD5 128-bit digest − HMAC with all algorithms

(8) Advanced Encryption Standard Accelerators (AESA) − Key lengths of 128-, 192-, and 256-bit (~40Gbps) − ECB, CBC, CTR, CCM, GCM, CMAC, XCBC, OFB, CFB, and XTS − Supports LTE 128-EEA2 / 128-EIA2

(8) Data Encryption Standard Accelerators (DESA) − DES (~40Gbps), 3DES (2K, 3K) ~20Gbps − ECB, CBC, OFB modes

(8) CRC Unit − CRC32, CRC32C, 802.16e OFDMA CRC (~48Gbps)

Header & Trailer off-load for the following Security Protocols: − IPSec, SSL/TLS, 3G RLC, PDCP, SRTP, 802.11i, 802.16e, 802.1ae

Job Queue

Controller

Descriptor

Controllers

DM

A

RT

IC

Queue

Interface

Job Ring I/F

DESA AESA

CHAs

MDHA

AFHA PKHA STHA

RNG4

KFHA

ZHA

TM

External Use 5

SEC 4.0+ Logical Block Diagram

• JQ Controller take inputs from:

− JR (Direct Mode)

− QI (DPAA Mode)

− RTIC

• DEscriptor COntroller

− 1-15, depending on product

• CHA Control Block

• Crypto Hardware Accelerator (CHA)

− Dedicated CHAs

AESA, MDHA, CRCA

− Pool CHAs

DES

RNG, KFHA

AFHA, PKHA, STHA

− Watch Dog Timer

• Monitors DECOs for prolonged inactivity

Queue Interface Job Prep Logic

Job Queue Controller

DECO Pool

DECO 0

Descriptor

Buffer

DECO 1

Descriptor

Buffer

DECO 2

Descriptor

Buffer

DECO 3

Descriptor

Buffer

DECO 4

R FDs

SP1 0 000

SP2 0 001

SP3 0 101

SP4 0 011

SP5 1 111

FQ FQ FQ FQ FQ

1 E E E D E

2 D E E D E

3 E E E E E

SP Status FQ ID List

Holding

Tank 0

Holding

Tank 1

Holding

Tank 2

Holding

Tank 3

Holding

Tank 4

Holding Tank Pool

Job Queues JR 0

JR 1

JR 2

JR 3

DM

A

Descriptor

Buffer

Watch

Dog

DESA

DESA

DESA

MDHA

CRCA

AESA

CCB 0 CCB 1 CCB 2 CCB 3 CCB 4

Arbiter Arbiter AFHA

Arbiter Arbiter KFHA

KFHA

RNG

RNG

Arbiter Arbiter Arbiter PKHA STHA f8 STHA f9

RTIC

MDHA

CRCA

AESA

MDHA

CRCA

AESA

MDHA

CRCA

AESA

MDHA

CRCA

AESA

CPU (JD, Data)

Buffer

Mgr

Queue

Manager DDR/CoreNet (Shared Desc, Frame)

TM

External Use 6

A DECO is Like a Processor …

• And the descriptors are like short programs!

• Each descriptor command (instruction) will cause the DECO to move or manipulate data, or issue commands to other blocks (i.e. DMA, CCB) to do their own special moves or manipulations

• The DECO starts processing once its descriptors are loaded into its descriptor buffer

• A Shared Descriptor, if present, starts at the beginning of the descriptor buffer, followed immediately by a Job Descriptor

• If there is no Shared Descriptor, the Job Descriptor starts at the beginning of the descriptor buffer

DECO N

Descriptor

Buffer

Hi!

I’m a

Job

Descriptor!

Hello

I’m a

Shared

Descriptor.

Have we

not met

before?

Math Reg 1

Math Reg 2

Math Reg 3

Math Reg 4

Cntl Reg

JQ Cntl Reg

Scatter Table

Gather Table

TM

External Use 7

Protocol Aware Data - It’s Nice to Share!

• For each packet processed, the following objects are needed by the

DECO and CCB

− Processing Instructions (Shared Descriptor commands)

− Encryption & Integrity Algorithm Keys

− Protocol State (Sequence Numbers, Anti-Replay lists)

• Fetching all these objects for each packet can take a lot of system

bandwidth, 2-3x the system bandwidth of small packet data

• The SEC offers options to share these objects across multiple

packets in a flow to avoid wasting bandwidth

TM

External Use 8

Hi!

I’m a basic

Job Descriptor!

Job Descriptors and Shared Descriptors

• Job Descriptors may completely define the job to be performed, or they can reference Shared Descriptors which contain the bulk of the processing instructions and context

Self-Contained Job Descriptor Job Descriptor with Shared Descriptor

Packet Dependent Packet Independent Packet Dependent

Hi!

I’m a basic

Job Descriptor!

Hello

I’m a

Shared

Descriptor.

Have we

not met

before?

Hello

I’m a

Self-Contained Job Descriptor.

We’ve never met,

but let me tell you everything

about processing this packet

Header LOAD KEYS LOAD CONTEXT OPERATION DATA LOAD DATA STORE

SHARE DESCRIPTOR LOAD KEY(S) LOAD CONTEXT OPERATION

JOB DESC (SHARE POINTER) SEQ IN POINTER SEQ OUT POINTER

TM

External Use 9

“Virtualized” Accelerator Interface

• SEC, PME, and DCE are integrated into the DPAA

− Acquire/release buffer pointers from/to BMan

− Dequeue and enqueue frames from QMan

• QMan “virtualizes” these haedware accelerators

• QMan provides processing “context” and instructions with dequeued frames

− e.g. crypto keys, IVs, ciphersuite

− Simplifies software’s use of accelerators

FQ

FQ

• •

• FQ

FQ

Requestor

Core

Accelerator:

SEC/PME/DCE

• •

• FQ

FQ

• • • FQ

FQ

• •

• FQ

FQ

• •

• FQ

FQ

Requestor

Core

• •

•

Priority and WIRR

Scheduler

WQ0...WQ7

Priority and WIRR

Scheduler

WQ0...WQ7

Priority and WIRR

Scheduler

WQ0...WQ7

Request Response Reponse Request

TM

External Use 10

Scalable Security Performance

• IPsec performance data across various platforms

− ESP Tunnel mode, bi-directional traffic at IMIX packet-size

− Large packet performance typically 2x IMIX

SEC 3.3 P1011/20

0.7 Gbps

SEC 3.1 P2020

1.0 Gbps

SEC 5.5 LS1020

1.5 Gbps

SEC 4.4 P1010,

PSC913x

2.0 Gbps

SEC 4.2 P204x, P3041,

P1023

4.0 Gbps

SEC 5.4 T1040

5.0 Gbps

SEC 4.0 P4080/40

10 Gbps

SEC 5.2 P5040/T2080

10 Gbps

SEC 5.0 T4240

20 Gbps

TM

External Use 11

SEC Engine Performance Factors

• Factors

− Frequency

− # of DECO (shared across algorithms)

− # of CHA (per algorithm)

− # of SEC engines

• Performance ~= Freq. x Min(#DECO, #CHA) x #SEC

• On chip SEC engines (e.g. in T4) have more AES/MD CHA

− Better suited for IPsec/SSL data processing

• Off chip SEC engines (e.g. C29x) have more PK CHA

− Better suited for public key crypto – control processing

TM

External Use 12

Security Enablement: Drivers,

Middleware and Applications

TM

External Use 13

Security Enablement – Philosophy

• Different customers have different requirements

• Create a structured hierarchy of layers which caters to all

requirements

• Provide complete solutions for certain use-case scenarios

Choice of

Security Software

Runtime Environment

Performance vs. Ease-of-

use

Algorithms, Protocols

Level of Integration

Bare-

metal/RTOS/

Linux®

kernel/user-

space

Intrusive or

non-intrusive

leverage of

offload

AES/3DES,

SHA1/MD5,

IPSec/SSL

Drivers/

Middleware/

Application/

Turnkey

Solution

TM

External Use 14

Linux User-space Linux Kernel Bare-metal/RTOS

User-space SEC driver* Kernel SEC driver

SEC RTA, Kernel and User-space Drivers

• Freescale provides drivers for both Linux® kernel and user-space − Use various means like Job-ring, QMan and PEX to access the SEC engine

• Freescale provides a SEC RTA library for bare-metal or RTOS environments − SEC RTA library re-used across environments

SEC RTA Lib/(Inline-Append)* SEC RTA Lib

Job-

Ring Qman* PEX

Linux Crypto

API

ASF Crypto

API

Crypto-Dev

API

QMan PEX

SEC User-space API*

OpenSSL EVP API

Customer

Middle-ware &

Applications

Customer Driver

& API

FSL & Customer

Middle-ware & Applications

FSL & Customer

Middle-ware & Applications

SEC RTA Lib

TM

External Use 15

SEC Run-Time-Assembler (RTA)

• RTA features

− API for writing SEC descriptors

− Descriptor Library with ready to use RTA descriptors

− Tests suite for development validation

• RTA Advantages

− Re-usable across environments

− Small software overhead

− Era version validation

− Support for self-referential code

− Easy to integrate into application

Basically, creates ‘special’ program to run on the SEC DECO engine

(AKA a descriptor)

TM

External Use 17

Using a SEC Driver: Performance vs. Ease-of-use

• Flow-awareness

− Application need not specify common information with every packet

E.g. keys, algorithms for a sequence of packets

− Application needs to ‘create’ a descriptor for the flow beforehand, and store it

• Asynchronous mode

− Application can process other packets while SEC is busy in crypto operations

− Needs to store/restore state

• Protocol-awareness

− SEC can perform auth + encryption in 1 pass instead of 2

− SEC can also maintain protocol state (e.g. anti-replay), and add/remove protocol headers

− Requires changes to software protocol stack

• Output buffer selection

− SEC fetches both in/out buffer from DDR

− Input = output buffer – best performance

− Needs careful buffer manipulation to retain headers, metadata

Flow-aware Flow-agnostic

Asynchronous Synchronous

Proto-aware 1-pass

No alloc HW alloc

Performance

Ease of use

Flow-awareness

Processing Context

Protocol-awareness

Output buffer selection

2-pass

SW alloc

TM

External Use 18

2-pass

Using a SEC driver: Performance vs. Ease-of-use

• Different API for performance or ease-of-use

− Highest performance

Kernel – ASF Crypto API

User-space – SEC user-space API

− Ease-of-use, standard

Kernel – Linux® Crypto API

User-space – OpenSSL EVP API

• Best of both worlds ??

− Freescale provides optimized middleware packages

ASF – IPsec with ESP Tunnel/Transport offload

OpenSSL with handshake and record-layer offload

− Middleware packages provide standard protocol API

PF_KEY/XFRM compatible ASF-API

Open-SSL API

− Hides details of SEC API interaction from customer application

Flow-aware Flow-agnostic

Asynchronous Synchronous

Proto-aware 1-pass

No alloc SW alloc HW alloc

Highest

Performance

Least

Intrusive,

Standard

ASF Crypto API,

SEC User-space API Linux

Crypto API OpenSSL

EVP API

TM

External Use 19

Algorithms and Protocols supported

Driver/API Asymmetric

/ others

Symmetric 2-

pass

Symmetric 1-pass Protocol

SEC – RTA

Lib

PKCS: RSA,

DSA, EC

RNG

Enc: AES-CBC, DES,

3DES

Auth: MD5, SHA*(+

HMAC variants)

IPSec: AES-CBC/3DES-CBC +

HMAC-SHA*/MD5, AES-GCM

SSL: AES-CBC/3DES-CBC +

HMAC-SHA*/MD5

IPSec: ESP-Tunnel-

encap/decap

SSL: Record layer

encap/decap

Linux

Crypto API

IPSec: AES-CBC/3DES-CBC +

HMAC-SHA*/MD5, AES-GCM

ASF Crypto

API

Auth: HMAC-MD5/SHA* IPSec: AES-CBC/CTR/3DES-

CBC + HMAC-SHA*/MD5, AES-

GCM/CCM

IPSec: ESP-Tunnel-

encap/decap

OpenSSL

EVP-API

(crypto-dev)

PKCS: RSA,

DSA, EC

RNG

Enc: AES-CBC, DES,

3DES

Auth: MD5, SHA*(+

HMAC variants)

Kasumi/Snow/ZUC-f8/f9

SSL: AES-CBC/3DES-CBC +

HMAC-SHA*/MD5, AES-GCM

SEC User-

space driver

PKCS: RSA,

DSA, EC

Kasumi/Snow/ZUC-f8/f9

IPSec: AES-CBC/3DES-CBC +

HMAC-SHA*/MD5, AES-GCM

SSL: AES-CBC/3DES-CBC +

HMAC-SHA*/MD5

IPSec: ESP-Tunnel-

encap/decap

LTE: PDCP Control/

Bearer encap/decap

SSL: Record layer

encap/decap

Black – SDK 1.5

Green – SDK 1.6

Orange – SDK 1.7

Red – SDK 1.7+

Italics - SEC 4.x/5.x only

Regular - SEC 4.x/5.x + C29x

TM

External Use 21

A Note on SEC Integrations

• SEC engine and drivers support a wide variety of applications

− Enterprise/SMB VPNs – IPsec

− Wireless backhaul – IPsec, PDCP

− Data-center – SSL

− WLAN backhaul – CAPWAP/DTLS

− Control-plane options for above – PKCS, RNG

• SEC engine and drivers do not dictate runtime environment − Can implement either in user-space or in kernel space (or RTOS)

− However, applications tend to stick to legacy choice of environment E.g. IPsec in kernel space (Linux® native IPsec, Strong/Open-Swan)

E.g. SSL in user space (OpenSSL)

− Hence integrations in following slides tend to follow popular open-source alternatives.

TM

External Use 22

IPsec: Native Linux®

• Linux stack supports IPsec data-path natively.

− Uses SEC engine services via standard Linux crypto API

− Provides standard PF_KEY/Net-Link interface to configure data path

• Performance

− ~20-30x better than software crypto libraries

− Supports asynchronous, 1-pass and 2-pass offloads

• Control-plane

− Setkey for manual SA setup

− Raccoon/StrongSwan IKE daemons for auto SA setup (internally use OpenSSL for crypto)

Kernel SEC driver

SEC RTA Lib *

Job-

Ring

Linux Crypto API

Ethernet

driver

Ethernet SEC

Linux NW Stack

Routing, ARP IPsec XFRM

Raccoon/StrongSwan

PF_KEY/Net-Link API

IKE Daemon Set-key

Op

en

SS

L

EV

P A

PI

Cry

pto

-De

v

TM

External Use 23

IPsec: Native Linux + ASF

• ASF (Application Specific Fast-Path)

− Optimized IPsec data path implementation

− Uses SEC engine via ASF Crypto-API

− Integrates seamlessly with Linux native IPsec

− Can integrate with other IPsec stacks too – provides protocol-level ASF-API

• Performance

− 2x to 3x higher than native Linux IPsec

− Optimized flow-caching, IPsec processing

− Leverages asynchronous, flow-aware, protocol offload, in-place processing to achieve this

− Leverages QM where available

• Control-plane

− Integrates seamlessly (under-the-hood) with Linux native IPsec → no special integration required

− Setkey, Raccoon, StrongSwan all supported

Kernel SEC driver

SEC RTA Lib *

QMan

ASF Crypto

API

Ethernet

driver

Ethernet SEC

Linux NW Stack

Routing,

ARP IPsec XFRM

Raccoon/StrongSwan

PF_KEY/Net-Link

API

IKE Daemon Set-key

Application Specific Fast-Path

IPsec Routing, ARP

ASF-API

Op

en

SS

L

EV

P A

PI

Cry

pto

-De

v

Job-

Ring

Linux

Crypto

TM

External Use 24

IPsec: Performance Comparison – Native Linux® vs. ASF

• IPsec performance data for ESP-Tunnel-mode using AES-128 + SHA1

ASF provides up to 4x performance increase compared to Linux

T4240 P4080

TM

External Use 25

IPsec: VortiQa IPsec Solutions

• VortiQa IPsec solutions

− Provides complete turnkey solution for IPsec VPN gateways, SMB-gateways, wireless backhaul

− Complete with IKE daemon and configuration tools (internally use OpenSSL for crypto)

• Why go for VortiQa software

− Commercial-grade

FIPS compliant

Extensive testing

Several field deployments

− Extra features – e.g.

Dead-peer detection, High availability, IKEv2

− Performance

Leverages ASF for data path

− Support

Maintenance, bug fixes

Customization services with Services and Support Organization

Kernel SEC driver

SEC RTA Lib

Job-

Ring QMan

ASF Crypto

API

Ethernet

driver

Ethernet SEC

Linux NW

Stack

Routing,

ARP VortiQa IPsec

VortiQa MSBG Application

VortiQa IPsec API

IKE Daemon CLI/HTTP

Application Specific Fast-Path

IPsec Routing, ARP

ASF-API

Op

en

SS

L

EV

P A

PI

Cry

pto

-De

v

Linux

Crypto

TM

External Use 26

IPsec: Rolling your own

• Customer has own IPsec/IKE stack

• In kernel, can use either Linux® crypto API or ASF crypto API for SEC offload

• Alternative is to move entire stack to user-space and use user-space drivers/API

− See further slides

• Recommendation

− ASF abstracts out SEC integration details and gives highest performance

− Configuration from kernel and user-space

− Ready to ship solution

− Commercial support, customization services available via Services and Support organization

Kernel SEC driver

SEC RTA Lib

Job-

Ring QMan

ASF Crypto

API

Ethernet

driver

Ethernet SEC

IPsec Routing, ARP

ASF-API

Linux

Crypto API

Customer IPSec stack

IPsec

IPsec API

IKE Daemon CLI/HTTP

Op

en

SS

L

EV

P A

PI

Cry

pto

-De

v

TM

External Use 27

SSL: Today – Standard OpenSSL with crypto-dev

• OpenSSL is primarily a user-space application

− Hence requires to use SEC engine offloads from user-space

• Enter Crypto-Dev

− Built over existing Linux® Crypto API

− Hooks in with OpenSSL libcrypto layer

• Advantage

− Provides standard OpenSSL API

− Seamless integration for SSL applications like Apache/Nginx

• Drawbacks

− Uses synchronous interface

− No protocol awareness

− No flow awareness

Kernel SEC driver

SEC RTA Lib

JR

Linux Crypto API

Ethernet

driver

Ethernet SEC

Linux Stack

TCP/IP

Crypto-Dev API

Crypto-Dev

OpenSSL

Lib-crypto/EVP API

Sockets

Handshake Record Layer

Applications

Apache Nginx

OpenSSL API

PEX

TM

External Use 28

SSL: Future – Optimized OpenSSL with User-space Driver

• Complete processing in user-space

− No overheads of context switching

− No overheads of buffer copying

• User-space drivers

− SEC driver

− Ethernet driver

− Part of USDPAA framework

− Directly interface with HW via mapped address regions (UIO)

• User-space TCP stack

− Ported from FreeBSD

− Highly optimized for FSL DPAA hardware

• Currently under development

User-space SEC driver

SEC RTA Lib

QMan

SEC User-space API

User-space

Ethernet

driver

Ethernet SEC

US-TCP

TCP/IP

OpenSSL

Lib-crypto/EVP API

Sockets

Handshake Record Layer

Applications

Apache Nginx

OpenSSL API

PEX

TM

External Use 29

Customer SSL

SSL: Rolling your own - A

• Customer has own SSL stack.

− Relies on OpenSSL EVP API for SW or HW crypto

− Relies on standard BSD sockets for transport

• Option A

− No special user-space ‘framework’ awareness

− Use crypto-dev integration via EVP API

− Use standard Linux NW stack TCP

− Lower performance due to context switching.

• Option B

− Needs user-space framework – USDPAA

− No change in existing EVP or socket API

− Special API extensions available for higher performance (zero-copy, async)

• Recommendation

− Continue to use OpenSSL EVP API and BSD Socket API

− Leverage user-space framework, extensions if higher performance is required.

Kernel SEC driver

SEC RTA Lib

JR

Linux Crypto API

Ethernet

driver

Ethernet SEC

Linux Stack

TCP/IP

Crypto-Dev API

Crypto-Dev

OpenSSL Lib-crypto/EVP API

Sockets

Handshake Record Layer

Customer Applications

Apache Nginx

SSL API

PEX

TM

External Use 30

User-space SEC driver

SEC RTA Lib

QMan

SEC User-space API

User-space

Ethernet

driver

Ethernet SEC

US-TCP

TCP/IP

Sockets

PEX

Customer SSL

SSL: Rolling your own - B

OpenSSL Lib-crypto/EVP API

Handshake Record Layer

Customer Applications

Apache Nginx

SSL API

• Customer has own SSL stack.

− Relies on OpenSSL EVP API for SW or HW crypto

− Relies on standard BSD sockets for transport

• Option A

− No special user-space ‘framework’ awareness

− Use crypto-dev integration via EVP API

− Use standard Linux NW stack TCP

− Lower performance due to context switching.

• Option B

− Need user-space framework – USDPAA

− No change in existing EVP or socket API

− Special API extensions available for higher performance (zero-copy, async)

• Recommendation

− Continue to use OpenSSL EVP API and BSD Socket API

− Leverage user-space framework, extensions if higher performance is required.

TM

External Use 31

Security Roadmap

• What’s coming in SDK 1.6 (Q2-2014) ?

− Asymmetric key support for both on-chip SEC and C29x

− New single-pass SSL symmetric key – AES-192/256-CBC + HMAC-SHA1

− Benchmarking data for OpenSSL performance with on-chip SEC and C29x

• What to expect from SDK 1.7 (Q4-2014) ?

− Standardization of SEC RTA library across environments, platforms.

− AES-GCM support for SSL

− SEC user-space driver integration with OpenSSL EVP

TM

External Use 32

Summary

• Freescale has a scalable portfolio of Security engines

− Both on-chip and off-chip/co-processor options

− Supports a wide variety of algorithms and protocols

− Designed for high performance/watt

• Freescale provides various options for leveraging security offloads

− Drivers providing access for both kernel and user-space applications

− Support both standard, easy-to-use API & performance-oriented API

− Middleware packages like ASF and OpenSSL optimized for performance

and provide standard configuration interface

− Complete solutions for select market segments from VortiQa software

TM

© 2014 Freescale Semiconductor, Inc. | External Use

www.Freescale.com