Measuring the Performance and Energy Cost of Cryptography in IoT Devices

Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Measuring the
Performance and Energy
Cost of Cryptography
in IoT Devices
Peter Torelli
President/CTO
EEMBC
Hannes Tschofenig
Senior Principal Engineer
Arm

2Copyright © 2018 Arm TechCon, All rights reserved.
#ArmTechCon
Agenda
Motivation
EEMBC & SecureMark-TLS
• Concepts
• Setup
• Score
• Early results
Upcoming work

#ArmTechCon
Why do we care?

#ArmTechCon
IoT Devices cannot do state-of-the-art crypto, right?
Wrong!
We looked at the performance of various state-of-the-art
crypto operations on a range of MCUs.
• Presented the investigations to the Internet Engineering Task Force
(IETF).
• Provided input to the 2015 NIST workshop on lightweight cryptography.
Hope was that others (e.g., researchers) help analyse the
performance on other MCUs and do additional tests.

#ArmTechCon
Some time later…
Unfortunately, there was more interest in inventing new algorithms (“lightweight crypto”
and in “Post-Quantum Crypto”) than in analysing today’s algorithms on off-the-shelf
hardware.
Often published results are referring to estimates and simulations rather than measured
performance.
We cannot run the tests on the wide range of MCUs from different vendors ourselves.
Did we reach a dead end?

#ArmTechCon
IoT security desperately needed
IoT devices comprise an enormous attack surface and ever-increasing list of attacks
against IoT devices published.
Best current practice recommendations from various organizations (including ENISA, the
GSMA, or OWASP) recommend utilizing state-of-the-art crypto, including Transport Layer
Security (TLS) for protecting communication.
How do developers ascertain both the power and performance costs of implementing
crypto, and particularly TLS, in their design for different configurations of hardware and
software?

#ArmTechCon
Embedded Microprocessor
Benchmark Consortium (EEMBC)
to the rescue

#ArmTechCon
Embedded Microprocessor
Benchmark Consortium (EEMBC)
It turns out that there is an organization that develops benchmarks for processors and MCUs.
It has been doing this since the late ‘90s.
For example, CoreMark is a benchmark that measures
the performance of CPU used in embedded systems.
EEMBC has established groups working on benchmarks for IoT:

#ArmTechCon

#ArmTechCon
SecureMark-TLS is a synthetic benchmark that models a TLS handshake without actually running
the handshake. Starting point is the TLS_ECDHE_ECDSA_WITH_AES_128_CCM ciphersuite.
It measuring the performance and power consumption.
It does this using the IoTConnect framework: a physical test harness and a firmware API that
enables a wide variety of energy and performance benchmarking capabilities
The firmware API is generic enough to facilitate the use of different software and hardware
implementations of cryptographic functions and primitives.
The reference implementation uses Mbed TLS for crypto.

#ArmTechCon
Full TLS handshake
ServerClient
ClientHello
ServerHello, Certificate, ServerKeyExchange,
CertificateRequest, ServerHelloDone
Certificate, ClientKeyExchange,
CertificateVerify, [ChangeCipherSpec], Finished
[ChangeCipherSpec], Finished
Application Data
Focused on
• Mutual, public key
based authentication
• ECC crypto with NIST P256r1 curve
• Flat certificate hierarchy
• AES-128-CCM
Legend:
*: optional message
[]: Not a handshake message.

#ArmTechCon
TLS Handshake Crypto-primitive Analysis Map
State Name #
client hello 1
server hello 2
certificate 3
server key exchange 4
certificate request 5
server hello done 6
certificate 7
client key exchange 8
certificate verify 9
change cipher spec 10
finished 11
change cipher spec 12
finished 13
Handshake State #
Primitive Usage 1 2 3 4 5 6 7 8 9 10 11 12 13
AES ECB / ENC
AES ECB / ENC
AES ECB / ENC
AES GCM / DEC
AES GCM / ENC
ECDH
ECDSA.SIGN
ECDSA.VERF
SHA256
SHA256
SHA256
SHA256
SHA256
SHA256
SHA256
SHA256
SHA256
Evaluated “states” of the reference implementation  13
The benchmark measures the TLS handshake crypto
cost and speed without time-consuming setup of an
actual client & server!
Figure: State Names
Figure: Primitive load per state
(a gray box indicates a context for that primitive is active)

#ArmTechCon
The IoTConnect Framework
Extensible framework with nano-
Joule accuracy, wired and wireless
interfaces, with a hardware setup
cost of <US$200*
* Note, this is the cost of the hardware from 3rd parties
(e.g., Digikey, Farnell). Host software and DUT benchmark
firmware licensed separately from EEMBC directly.
** Radio manager not required for SecureMark or
ULPMark
Device Under
Test (DUT)
BLE
ZigBee
LoRa
thread
802.11x
Host System
I2C
SPI
GPIO
UART
IO Manager Energy Monitor Radio Manager**

#ArmTechCon
Actual Hardware Build
The DUT (center) is powered by the energy
monitor (left).
The IO Manager (left, under EMON) acts as
both sensor emulation and communication
proxy.
The Radio Manager (right) acts as the wireless
gateway (not needed for SecureMark)
The Host (not shown) coordinates all four
subsystems.

#ArmTechCon
One Framework, Many Benchmarks
Deploying one extensible
framework keeps the
environment consistent between
new benchmarks.
Same UI, same firmware pattern,
same hardware connectivity
reduces engineering effort to
port new hardware.

#ArmTechCon
Application Programming Interface
Generic API for talking to host software via UART (3 functions)
Benchmark-specific profile for executing content (~6 functions per 5 primitives: SHA256,
ECDH, ECDSA, AES/ECB, AES/CCM)
Ported to ARC SSL (Synopsys), mbedTLS, STMicro Crypto32 software and STMicro
hardware AES acceleration

#ArmTechCon
Benchmark composition
SecureMark = inverse sum of energy x scale
factor => single integer score representing TLS
energy efficiency (bigger is better)
Performance and power also provided as part
of analysis
Deep dive into zoomable energy graph

#ArmTechCon
Incremental porting processes makes bring-up easy…
Creating and submitting SecureMark-TLS scores
Port UART
interface
Port Crypto
API
Optimize
Score
Setup
H/W
Submit
Score

#ArmTechCon
Preventing “cheating”
Randomize Keys + Check Results
• Before testing the Host UI provides random keys and pre-generated plaintext / cyphertext
• After testing the expected responses are compared by the Host
• No way to fake performing the operation
Disclosures + Certification + Community Policing
• Submitted scores must appear on website (legal requirement for licensees) with disclosure
• Certified scores are highest quality: EEMBC internally reviews source code and makes it available to members
• Members often reproduce competitor’s scores: disabling a hardening feature for a better score would be exposed

#ArmTechCon
First results and observations

#ArmTechCon
The first published SecureMark-TLS score!
https://www.eembc.org/securemark/scores.php
Detailed results include information about
• Compiler, linker, and toolchain
• Crypto library (mbedTLS 5.4.0) plus security-relevant optimizations, and
• Detailed energy and performance subscores for AES ECB Encrypt, AES CCM
Encrypt/Decrypt, ECDH p256r1, ECDSA p256r1 Sign & Verify, and SHA256.
• For example: The ECDSA sign operation takes 438 msec and the verify operation needs 1500 msec

#ArmTechCon
First SecureMark-TLS Results, Overall
Comparing two platforms (Plat A/B) and
two libraries (Lib A/B)
Platform A has no hardware acceleration
Platform B has full hardware acceleration
Lib A’ uses compiler optimizations
Acceleration clearly rewarded
0 2000 4000 6000 8000 10000 12000
Plat A, Lib A
Plat A, Lib A'
Plat A, Lib B
Plat B, Lib A
Plat B, Accelerated
SecureMark-TLS Prelimanary Scores
1200 1300 1400 1500 1600
Plat A, Lib A
Plat A, Lib A'
Plat A, Lib B

#ArmTechCon
First SecureMark-TLS Results, per Primitive Class
Zooming in on energy costs relative to
baseline
Enormous gains in energy efficiency
using dedicated hardware
Library and compiler options vary
0.0 0.5 1.0 1.5 2.0 2.5
AES ECB
AES CCM
SHA
ECDH
ECDSA
Energy Cost per Platform Relative to Platform
A, Library A
Plat A, Lib A
Plat A, Lib A'
Plat A, Lib B
Plat B, Lib A
Plat B, Accelerated

#ArmTechCon
Summary and next steps

#ArmTechCon
Summary
With SecureMark-TLS we created the first IoT security benchmark.
It will help developers and designers to know upfront what performance and power
consumption to expect from a given MCU for state-of-the-art crypto
• High level score available for easy comparison
• Detailed data within the disclosure form
Details to be found at www.eembc.org/securemark

#ArmTechCon
Next steps
EEMBC is ready to receive score submissions
This was the first version of the SecureMark-TLS benchmark. We are not standing still and
have started to brainstorm about the direction this could go.
Performance scoring of SecureMark-TLS
Possible work areas: RAM consumption, additional algorithms and …
Join us in EEMBC or help submit new scores

#ArmTechCon
27
Acknowledgments go to the members of the EEMBC
SecureMark working group, particularly the chairs Mike
Borza and Ruud Derwig.
Thank you!

Measuring the Performance and Energy Cost of Cryptography in IoT Devices

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Measuring the Performance and Energy Cost of Cryptography in IoT Devices

Ähnlich wie Measuring the Performance and Energy Cost of Cryptography in IoT Devices (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Measuring the Performance and Energy Cost of Cryptography in IoT Devices