Sensor Security: A Kaleidoscopic View Ren Struik (Certicom - - PowerPoint PPT Presentation

July 2, 2009

René Struik (Certicom Research) Slide 1

RFIDSec 2009

Sensor Security: A Kaleidoscopic View

René Struik (Certicom Research) E-mail: rstruik@certicom.com

Certicom Corp. is a wholly owned subsidiary of Research in Motion, Ltd.

July 2, 2009

René Struik (Certicom Research) Slide 2

RFIDSec 2009

2

Wheeling-Pittsburg Steel Corporation

Photo courtesy Dust Networks

July 2, 2009

René Struik (Certicom Research) Slide 3

RFIDSec 2009

3

The Promise of Wireless The Promise of Wireless

The Economist, April 28, 2007

July 2, 2009

René Struik (Certicom Research) Slide 4

RFIDSec 2009

A Note on Security and Ease of Use

This document is provided strictly for the purpose of gathering information leading to the development of an ISA standard, recommended practice or technical report. Copies may be reproduced and distributed, in whole or in part, but

• nly for the following purposes:
• Review of and comment on the ISA-SP100 draft proposal
• Submission to the ISA-SP100 Committee
• Informing and educating others about the ISA-SP100

draft standard development process.

July 2, 2009

René Struik (Certicom Research) Slide 5

RFIDSec 2009 Source: D. Balfanz, G. Durfee, R.E. Grinter, D.K. Smetters, P. Stewart, “Network-in-a-Box: How to Set Up a Secure Wireless Network in under a Minute,” in Proceedings of the 13th USENIX Security Symposium, August 9-13, 2004.

Security and Ease of Use

“Computer users have been taught for years that computer security systems can’t be effective unless they are complex and difficult to use. In reality, this conventional wisdom is completely wrong.” ⎯ Lorrie Faith Cranor, Carnegie Mellon University Security technology can make trust lifecycle management intuitive and hidden from the user.

July 2, 2009

René Struik (Certicom Research) Slide 6

RFIDSec 2009

Ease of Configuration and Reconfiguration

Ease of configuration:

• Merging of networks
• Partitioning of networks
• Device portability and orphaning
• Hand-over of control (remote, backup)

July 2, 2009

René Struik (Certicom Research) Slide 7

RFIDSec 2009

Security and Ease of Use – Bridging the Gap

Challenge: Bridge the gap between state-of-the-art security that is known and security that is actually being used.

Education gap. Conventional wisdom is that “computer security systems can’t be effective unless they are complex and difficult to use”. While this may once have been true, the security profession has witnessed dramatic insights over the last ten years, which has not all been embraced yet by the field. Perception gap. Conventional wisdom is that security technologies are too expensive to implement with sensor and control networks, due to energy constraints, computational and storage constraints. Anno 2008, this perception is challenged for all but the most mundane devices. Examples: e.g., Bluetooth v2.1, ZigBee Smart Metering, and RFID e-Passport. Affordability gap. Conventional wisdom is that the licensing cost of security technologies may present a hurdle. Licensing models, such as those used with the consumer electronics industry, may have some merit for ubiquitous computing as well, since both are concerned with mass-scale deployment of networked devices ("the internet of things") and enforcement of compliance. Examples: ZigBee Smart Energy licensing model for public-key technology; flexible business models for deployment tailored to best fit requirements of various players in the supply chain (i.e., can be moved to most suitable point, so as to promote wide-scale adoption).

July 2, 2009

René Struik (Certicom Research) Slide 8

RFIDSec 2009

Devices and Device Ids

This document is provided strictly for the purpose of gathering information leading to the development of an ISA standard, recommended practice or technical report. Copies may be reproduced and distributed, in whole or in part, but

• nly for the following purposes:
• Review of and comment on the ISA-SP100 draft proposal
• Submission to the ISA-SP100 Committee
• Informing and educating others about the ISA-SP100

draft standard development process.

July 2, 2009

René Struik (Certicom Research) Slide 9

RFIDSec 2009

PHY* PHY* Data Link TCP /IP Network Transport APP

Gateway

Data Link Network Data Link*

“Tunnel”

PHY Data Link Network

Router

APP Transport Network Data Link PHY

Edge Node

Network PHY

Source: Networking-Transport Diagrams ISA SP100.11a (Jay Werb, March 1, 2007).ppt

July 2, 2009

René Struik (Certicom Research) Slide 10

RFIDSec 2009

PHY functions Data Link functions Network functions Transport functions APP functions Device- wide parameters PHY parameters Data Link parameters Network parameters Transport parameters APP parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device potential implementation Address translation table DeviceID DLL address MAC address APP address Trans address Handed out by IEEE-RAC; static throughout lifecycle (no cloning, copying, etc.) short MAC add = Dynamically assigned; can be changed at will

Full stack device, including per-layer and shared parameters

Trusted module includes all security processing and secure and authentic storage

• f all keying material of the

device, as well as policies

July 2, 2009

René Struik (Certicom Research) Slide 11

RFIDSec 2009

PHY functions Data Link functions Network functions Transport functions APP functions Device- wide parameters PHY parameters Data Link parameters Network parameters Transport parameters APP parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device potential implementation Address translation table DeviceID DLL address MAC address APP address Trans address Handed out by IEEE-RAC; static throughout lifecycle (no cloning, copying, etc.) short MAC add = Dynamically assigned; can be changed at will

Full stack device, including per-layer and shared parameters Trust binding

July 2, 2009

René Struik (Certicom Research) Slide 12

RFIDSec 2009

PHY functions Data Link functions Network functions Transport functions APP functions Device- wide parameters PHY parameters Data Link parameters Network parameters Transport parameters APP parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device potential implementation Address translation table DeviceID DLL address MAC address APP address Trans address Handed out by IEEE-RAC; static throughout lifecycle (no cloning, copying, etc.) short MAC add = Dynamically assigned; can be changed at will

Full stack device, including 802.15.4-2006 transceiver

July 2, 2009

René Struik (Certicom Research) Slide 13

RFIDSec 2009

PHY functions Data Link functions Network functions Device- wide parameters PHY parameters Data Link parameters Network parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device potential implementation Address translation table DeviceID DLL address MAC address Handed out by IEEE-RAC; static throughout lifecycle (no cloning, copying, etc.) short MAC add = Dynamically assigned; can be changed at will

“Lower”-stack device, including 802.15.4-2006 transceiver

July 2, 2009

René Struik (Certicom Research) Slide 14

RFIDSec 2009

PHY functions MAC functions Device- wide parameters PHY parameters MAC parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device potential implementation Address translation table DeviceID MAC address Handed out by IEEE-RAC; static throughout lifecycle (no cloning, copying, etc.) short MAC add = Dynamically assigned; can be changed at will

“Lower”-stack device, with just 802.15.4-2006 transceiver

July 2, 2009

René Struik (Certicom Research) Slide 15

RFIDSec 2009

PHY functions MAC functions Device- wide parameters PHY parameters MAC parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device potential implementation Address translation table DeviceID MAC address Handed out by IEEE-RAC; static throughout lifecycle (no cloning, copying, etc.) short MAC add = Dynamically assigned; can be changed at will

“Lower”-stack device, with just 802.15.4-2006 transceiver Trust binding at manufacturing

July 2, 2009

René Struik (Certicom Research) Slide 16

RFIDSec 2009

Network functions Transport functions APP functions Device- wide parameters Network parameters Transport parameters APP parameters AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device potential implementation Address translation table DeviceID APP address Trans address Handed out by IEEE-RAC; static throughout lifecycle (no cloning, copying, etc.) = Dynamically assigned; can be changed at will

“Upper”-stack device, without 802.15.4-2006 transceiver

July 2, 2009

René Struik (Certicom Research) Slide 17

RFIDSec 2009

PHY functions Data Link functions Network functions Transport functions Device- wide parameters PHY parameters Data Link parameters Network parameters Transport parameters APP1 funct(1) APP parm(1) AES RNG ECC Security protocols Security policies Keying material DeviceID communication stack layer-specific parameters shared functions and parameters Device potential implementation Address translation table DeviceID DLL address MAC address APP addr(1,…,n) Trans address Handed out by IEEE-RAC; static throughout lifecycle (no cloning, copying, etc.) short MAC add = Dynamically assigned; can be changed at will

Multi-application device, including 802.15.4-2006 transceiver

APP funct(n) APP parm(n) … …

July 2, 2009

René Struik (Certicom Research) Slide 18

RFIDSec 2009

Multi-application device

Stack device (communication module) Application “plug-ins”

This multi-application module is a single device – Device A: takes care of complete communication stack – “Plug-ins” App(1, …,n): handle applications, e.g., FieldBus, HART, PROFIBUS Different applications are independently sourced, but rely on shared communication stack and “open” trust model within device A

A Multi-application Module (single device) … App(1) App(2) App(n-1) App(n)

July 2, 2009

René Struik (Certicom Research) Slide 19

RFIDSec 2009

Non-monolithic stack device, including 802.15.4-2006 transceiver “router”, akin to WiFi router with multiple transceivers

“Lower”-stack devices (plug-in transceivers) “Upper”-stack device (“router function”)

Conceptually, this device is a little network, with n+1 nodes – Device B: takes care of upper-stack/ “transport-and-up” traffic – Devices A1, …, An: take care of lower-stack/ “kicking traffic to next hop” Different components are independently sourced, with individual trust routines and individual (partial) communication stack

A1 B

A(n-1)

A2 An … Multi-device Module

July 2, 2009

René Struik (Certicom Research) Slide 20

RFIDSec 2009

Deployment Scenarios

July 2, 2009

René Struik (Certicom Research) Slide 21

RFIDSec 2009 “Perimeter Security” “No Perimeter Security”

Acceptability test: Yes/No?

Idealized Provisioning

July 2, 2009

René Struik (Certicom Research) Slide 22

RFIDSec 2009

“Hand carry key in a ‘safe’”

“Perimeter Security” “No Perimeter Security”

Cryptographic boundary: Process Control Domain

Symmetric-key Based Provisioning

July 2, 2009

René Struik (Certicom Research) Slide 23

RFIDSec 2009 “Perimeter Security” “No Perimeter Security”

Cryptographic boundary: Device itself (intra-device secure module) Acceptability test: Yes/No?

Public-key Based Provisioning (1)

July 2, 2009

René Struik (Certicom Research) Slide 24

RFIDSec 2009

Acceptability test: Yes/No?

Public-key Based Configuration (2)

Acceptability test based on

• Device Id
• Tag Name
• Device Label
• Open enrolment
• Proximity-based techniques

… Trust management via device identities

Trusted module

• AES, ECC, RNG
• Security policy

engine

• Storage of keys

July 2, 2009

René Struik (Certicom Research) Slide 25

RFIDSec 2009

Deployment Scenarios1

Scenario #1: mix-and-match of nodes from different vendors Scenario #2: addition of nodes to operational network Scenario #3: security audit Scenario #4: device repair and replacement (roaming in/out different user sites) Scenario #5: network separation (devices joining wrong network) Scenario #6: thwarting malicious attacks by (former) insiders Scenario #7: thwarting attacks by outsiders via insiders (held at ‘gunpoint’) Scenario #8: addition of subsystem (‘skid’) assembled elsewhere to operational network

1Deployment scenarios discussed with ZigBee, ISA SP100.11a user community

July 2, 2009

René Struik (Certicom Research) Slide 26

RFIDSec 2009

Ease of use. Trust lifecycle management appears the same as that of an unsecured network and relies on

• proper identification of devices (e.g., reading off a label of physical module);
• proper management of device roles (e.g., adding these to, resp. removing these

from a white list, e.g., via a workstation GUI). Thus, trust lifecycle management relies completely on handling of public information.

• Flexibility. Virtually no restrictions w.r.t. support for
• mix-and-match of devices from different vendors;
• changes to network topology (merging or partitioning of networks, device

replacement or addition, addition of pre-assembled subsystem);

• changes to device roles (e.g., smooth hand-over of system manager, security manager

roles, via ‘soft reboot’);

• back-up and failure recovery (since management fully relies on public information).

Desired Features and Benefits (1)

July 2, 2009

René Struik (Certicom Research) Slide 27

RFIDSec 2009

Minimizes trust dependencies. If secret information is never disclosed,

• Greatly reduced reliance on trustworthy personnel;
• Virtually no training requirements for operational personnel;
• Virtual removal of trust dependencies between different entities in value chain

(whether OEM, vendor, system integrator, installer, or user).

• Ease of security auditability.

Support for flexible deployment and business models. If no secret information is ever disclosed during a device’s or network’s lifecycle, network topology changes or device role changes present a ‘clean’ logical separation between state prior to and after such an event (thus, allowing subscription-based services, outsourced management, re- contracting, etc.). Enforcement of standards compliance. Enforced by only issuing a certificate to devices from vendors that passed conformance testing. No reliance on configuration tools and out-of-band configuration steps. A configuration tool may be used, but is not strictly necessary for trust enforcement.

Desired Features and Benefits (2)

July 2, 2009

René Struik (Certicom Research) Slide 28

RFIDSec 2009

Evaluation criteria (1)

1.

How does approach address deployment scenarios – per-scenario comparison 2. Vulnerabilities of devices/subsystems in transit from vendor to user 3. Dependencies on trustworthiness personnel 4. Simplicity 5. Ease of use 6. Flexibility 7. Minimizes dependencies 8. System resources (bandwidth, time, energy consumption, join time) 9. Availability (24/7)

• 10. Human element
• 11. Externalities (robustness, do we need special boxes, tools, etc.)
• 12. Does facilitate over-the-air provisioning
• 13. Interoperability
• 14. Implementation cost (incremental cost)
• 15. Where cost occurred?
• 16. Ability to put more data on device (as required to bootstrap behavior on

different layers)

July 2, 2009

René Struik (Certicom Research) Slide 29

RFIDSec 2009

Evaluation criteria (2)

• 17. Ability to put date on a device that does not have an 802.15.4 radio (e.g.,

gateway, backbone router, system manager), so that the same end state can be reached

• 18. Ability to de-provision device (i.e., bring back to ex-factory state and sell, e.g.,
• n e-bay to someone who can then still securely use it)
• 19. Number of tools required
• 20. Ability to move from devices between sites (e.g., smart sea containers) –

roaming in/out of different user sites

• 21. Economies of scale issues

July 2, 2009

René Struik (Certicom Research) Slide 30

RFIDSec 2009

Device Certificates

July 2, 2009

René Struik (Certicom Research) Slide 31

RFIDSec 2009

Certificate Generation (1)

A RA CA (qA, QA) QA IdA (IdA, QA) (IdA, QA) A N C (IdCA, WCA) A Policies (qA, QA), IdA

ConfigSet:=∅ CASet:=∅

IdA, CertCA(IdA,KeyInfoA), signCA Name server IdA InfoA Device roles Keying information Device information

A Ordinary device (qA, QA) ephemeral private/public key A IdA identifier of device A RA Registration authority (a, CertA) private key, resp. certificate A IdCA identifier of CA CA Certificate authority WCA public root key CA IdC identifier of C N Name server signCA signature over certificate info C Configuration manager KeyInfoA keying information for device A

(qA, QA), IdA

ConfigSet:={IdC} CASet:={(IdCA,WCA)}

(a, CertA), IdA

ConfigSet:={IdC} CASet:={(IdCA,WCA)}

(IdA, CertA)

qCA

July 2, 2009

René Struik (Certicom Research) Slide 32

RFIDSec 2009

Certificate Generation (2)

A RA CA (qA, QA) QA IdA (IdA, QA) (IdA, QA) A N C (IdCA, WCA) A Policies (qA, QA), IdA

ConfigSet:=∅ CASet:=∅

IdA, CertCA(IdA,KeyInfoA), signCA Name server IdA InfoA Device roles Keying information Device information

A Ordinary device (qA, QA) ephemeral private/public key A IdA identifier of device A RA Registration authority (a, CertA) private key, resp. certificate A IdCA identifier of CA CA Certificate authority WCA public root key CA IdC identifier of C N Name server signCA signature over certificate info C Configuration manager KeyInfoA keying information for device A

(qA, QA), IdA

ConfigSet:={IdC} CASet:={(IdCA,WCA)}

(a, CertA), IdA

ConfigSet:={IdC} CASet:={(IdCA,WCA)}

(IdA, CertA)

qCA

Bootstrapping mechanism Device identification

July 2, 2009

René Struik (Certicom Research) Slide 33

RFIDSec 2009

Device relationships (1)

(a, CertA), IdA

CASet:={(IdCA,WCA)}

A (a, CertA) IdA LabelA Device roles Keying information Device information

A Ordinary device (a, CertA) private key, resp. certificate A IdA identifier of device A CA Certificate authority WCA public root key CA IdCA identifier of CA

Type of binding

KeyInfoA keying information for device A LabelA label of device A logical link physical link

Example A: Public keys.

(IdCA, WCA) A WA IdA a LabelA CertCA(IdA, KeyInfoA) KeyInfoA

July 2, 2009

René Struik (Certicom Research) Slide 34

RFIDSec 2009

Networks vs. ad-hoc wireless networks

July 2, 2009

René Struik (Certicom Research) Slide 35

RFIDSec 2009

Communication technology

• Transmission technology (e.g., frequency band for radio transmissions if wireless)
• Anticipated data rates (including, e.g., breakdown depending on device type)
• Hearing range (i.e., range over which direct communication between static and moving devices

may be possible without routing)

• Cost factors (e.g., low power, low cost, low complexity devices)
• Special communication types (e.g., beacon and beacon-less communication)

Devices

• Anticipated application area of devices, networks

Network Characteristics

• Network topology (e.g., star network, mesh networks)
• Communication patterns (e.g., peer-to-peer, multicast, broadcast)
• Devices and their roles and capabilities (e.g., ordinary device, network coordinator)
• Intra-network behavior and inter-network behavior (roaming)

Interaction with outside world

• Gateway to other networks (e.g, node that communicates MAC service data units back and forth)
• Access to infrastructure (e.g., no online access to external infrastructure (external to network))

NOTE: Presentation relies on concepts only, but assumes distinct network coordinator role

Underlying network technology (varying details)

July 2, 2009

René Struik (Certicom Research) Slide 36

RFIDSec 2009

Access control to the network itself Restriction of access to scarce network resources to authorized devices only, to ensure objectives including the following:

• proper bandwidth allocation;
• protection of commands (e.g., those regulating network membership);
• power drain savings.

Control of access to message traffic between network devices Restriction of access to information secured between members of a group of network devices to precisely these group members. This includes any of the following

• bjectives:
• Confidentiality:

Prevent external parties from learning the content of exchanged messages.

• Data integrity/message authentication:

Prevent external parties from modifying or injecting messages in undetected way.

• Other (e.g., replay protection, timeliness, etc.)

Network security objectives

July 2, 2009

René Struik (Certicom Research) Slide 37

RFIDSec 2009

Wireless networking standards

Wireless Local Area Networks (WLAN)

• IEEE 802.11 family (11-55 Mbps and much higher)
• WiFi Alliance

Wireless Personal Area Networks (WPAN) Medium-rate WPAN

• Bluetooth: 1 Mbps
• Bluetooth Lite

High-Rate WPAN

• IEEE 802.15.3: 11-55 Mbps
• WiMedia Alliance, UWB Forum: up to 450 Mbps (using UWB)

Low-Rate WPAN

• IEEE 802.15.4: 20, 40, 250 kbps
• IEEE 802.15.4a
• ZigBee Alliance

Fixed/mobile broadband access standards (802.16, 802.20), 4G, 3GPP, etc. Ubiquitous computing standards, DRM, etc.

July 2, 2009

René Struik (Certicom Research) Slide 38

RFIDSec 2009

Sensor and control standards

Wireless Personal Area Networks (WPAN) Medium-rate WPAN

• Bluetooth: 1 Mbps
• Bluetooth Lite

Low-Rate WPAN

• IEEE 802.15.4: 20, 40, 250 kbps
• IEEE 802.15.4a (UWB), TG4c (China), TG4d (Japan), TG4f (RFID), TG4g

(SmartGrid PHY)

• ZigBee Alliance
• W/HART
• ISA SP100.11a
• IETF 6lowpan, RoLL
• NIST Smart Grid Initiative (EISA 2007 Legislation)

July 2, 2009

René Struik (Certicom Research) Slide 39

RFIDSec 2009

Applications (sensor and control networks)

• Toys and games
• Consumer electronics
• PC peripherals
• Home automation
• Building automation (HVAC)
• Healthcare
• Factory automation
• Industrial control
• Supply chain management
• Asset tracking & localization
• Homeland security
• Smart dust …

Potential of wireless sensors for industry [US Dept of Energy (Dec 2002)]

• efficiency improvement: 25%; emission reduction: 10%
• significant reduction of ‘wiring cost’; current range: from $50-100 to $2,000 per foot

(if hazardous environment) 2001 figure: ‘wiring cost’ of $100B with $11B sensor market [WINA (2003)]

July 2, 2009

René Struik (Certicom Research) Slide 40

RFIDSec 2009

Constraints (1)

Constraints for sensor networks High throughput is not essential, but rather

• Low energy consumption:

Lifetime of 1 year with 2 AAA batteries (@750 mAh, 2V) yields 85μA average power consumption, thus forcing ‘sleepy’ devices (802.15.4 uses 40-60 mW for Tx/Rx)

• Low manufacturing cost:

Low cost devices force small memory, limited computing capabilities (clock frequency: 4-16 Mhz; 10-32 kbytes ROM, 1-4 kbytes RAM, possibly no flash) Constraints for adhoc networks

• No centralized management:

No online availability of fixed infrastructure (so, decentralized key management)

• Promiscuous behavior:

Short-lived communications between devices that may never have met before (so, trust establishment and maintenance difficult)

• Unreliability:

Devices are cheap consumer-style devices, without physical protection (so, no trusted platform on device)

July 2, 2009

René Struik (Certicom Research) Slide 41

RFIDSec 2009

Constraints (2)

Security constraints for adhoc networks

• Decentralized key management:

Due to no online availability fixed infrastructure, but also very ‘sleepy’ nodes

• Flexible configuration and trust management:

Due to promiscuous, adhoc behavior, but also survivability requirements.

• Low impact of key compromise:

Due to unavailability of trusted platform (tamper-proofing, etc.)

• Automatic lifecycle management:

Due to virtual absence of human factor, after initialization Security constraints for sensor networks

• Implementation efficiency: protocols should use similar cryptographic building blocks
• Parallelism: design protocols have the similar message flows
• Low communication overhead: protocols must avoid message expansion if possible

July 2, 2009

René Struik (Certicom Research) Slide 42

RFIDSec 2009

Constraints (3)

Chip cost considerations Hardware vs. software cost (in USD)1

• Cost metrics of 0.33μ CMOS technology:

1k gates ≈ 0.5¢ 1 pin ≈ 0.5¢ RAM = 8 ROM 1 kbytes ROM ≈ ½ mm2 15k gates ≈ 1 mm2

• Cost x kbytes flash memory ≈ a + b x, where a is big constant (4-5 extra processes)

Note: Cost mainly determined by chip area (if mass produced)

• Cost ratios:

(1 kgates : 1kROM : 1 kRAM) = (1 : 7.5 : 60)

• Impact process technology:

Change from 0.33μ → 0.18μ CMOS technology yields area → 0.3 area.

1Figures indicative only, courtesy Melexis Telecom (June 2003)

July 2, 2009

René Struik (Certicom Research) Slide 43

RFIDSec 2009

Constraints (4)

Cryptographic building blocks

• Symmetric: all based on fixed block cipher, e.g., AES-128
• Public-key: all based on fixed elliptic curve, e.g., binary Koblitz curve K-163

1Figures on ATMel ATMega 128L processor, 16 MHz, 128K RAM 2Johann Großschädl, 2001

Block Cipher (AES) ECC (K-163)

ROM: 800-2,300 bytes RAM: 60 bytes ROM: 3-5 Kbytes1 RAM: 300 bytes ≈ 3,500 gates2 ROM: 1-2 Kbytes ≈ 6-7,000 gates

Software Hardware Hardware implementation cost

• AES-128. Cost: 3.5¢ → 1¢ (0.33μ → 0.18μ)
• K-163 curve. Cost: 2¢ → ½ - ¾¢ (0.33μ → 0.18μ) {Note: for K-283: 3¢ → 1¢}

Software implementation cost

• AES-128. Cost: 3 – 8.5¢ → 1 – 3¢ (0.33μ → 0.18μ)
• K-163 curve. Cost: 11 – 19 → 3.5 – 6¢ (0.33μ → 0.18μ)

Hardware: significantly lower power consumption

July 2, 2009

René Struik (Certicom Research) Slide 44

RFIDSec 2009

Conventional wisdom: Symmetric-key cryptographic functionality, let alone public- key cryptographic functionality, are expensive to implement with sensor networks. Status anno 2008: conventional wisdom challenged for all but most mundane devices. Examples: Bluetooth v2.1, ZigBee Smart Metering, RFID e-Passport.

Cost

Public Key Device DeviceId CA Id AttributeData

22 octets 8 octets 8 octets 10 octets

ProfileId Ctrl Serial# ManufacturerData

• ZigBee Smart Energy Profile Certificate Structure:
• Low-energy hardware implementations:

Smart Sensors1 RFID2 clock frequency 2 MHz 10 MHz #gates ~10 kgates ~100 kgates CMOS process 130nm 250nm Energy exp.: ~ 250 μJ < 100 μJ Computation signature verify point multiple

(total: 48 octets)

Sources:

1Certicom-internal 2SAC 2008 conference

Less than energy expenditure single IEEE 802.15.4 frame!

July 2, 2009

René Struik (Certicom Research) Slide 45

RFIDSec 2009

Security Architectural Framework

This document is provided strictly for the purpose of gathering information leading to the development of an ISA standard, recommended practice or technical report. Copies may be reproduced and distributed, in whole or in part, but

• nly for the following purposes:
• Review of and comment on the ISA-SP100 draft proposal
• Submission to the ISA-SP100 Committee
• Informing and educating others about the ISA-SP100

draft standard development process.

July 2, 2009

René Struik (Certicom Research) Slide 46

RFIDSec 2009

Security Architectural Framework: Overview (1)

Security mechanisms: 1. Public-key key establishment mechanism. Derivation of link key between two devices, based on authentic public keys of both parties, including evidence on whom this link key is shared with. 2. Symmetric-key key transport mechanism. Secure transfer of data key from

• ne device to other(s), based on link key(s) between sender and recipient(s).

3. Symmetric-key data transfer mechanism(s). Secure and/or authentic data transfer between devices that share the data key (confidentiality/data integrity/authenticity). Security policy: …

Note: Security architectural framework with symmetric-key key establishment is very similar to that with public-key key establishment (details omitted here).

July 2, 2009

René Struik (Certicom Research) Slide 47

RFIDSec 2009

key distribution A B Data key repository Data key maintenance Data key repository Data key maintenance Wrapped data key info Wrapped data key info data transfer A B Wrapped data Wrapped data Encryptor/ decryptor Encryptor/ decryptor data data Data key Key info Key info Data key Upper layers Upper layers Network and down Network and down ACL Maintenance

ACL ACL

ACL Maintenance ACL initialization ACL initialization

B

A Authentication, key establishment Wrapped public key info Extracted public key info Wrapped public key info Extracted public key info Public key verification CA key initialization Certificate maintenance Public key verification CA key initialization Certificate maintenance (Link key, A, B) (Link key, A, B)

Security Architectural Framework: Overview (2)

July 2, 2009

René Struik (Certicom Research) Slide 48

RFIDSec 2009

Security Architectural Elements: – Security Policy Model

– Secure Data Transfer – Authorization

July 2, 2009

René Struik (Certicom Research) Slide 49

RFIDSec 2009

Security Policy Model

July 2, 2009

René Struik (Certicom Research) Slide 50

RFIDSec 2009

Devices and their Roles (1)

Role model

• Security manager. Sole source of local trust management.
• Facilitates establishment of symmetric keying material between ordinary devices;
• Facilitates maintenance of keying relationships;
• Enforces security policy.
• Ordinary device. Part of Network or could become part hereof.
• Responsible for secure processing and storage of keying material;
• Responsible for maintenance of its own Access Control List (ACL) and other lists.
• Coordinator. Potential source of local message control (in Network).
• Facilitates admission of ordinary devices to the Network;
• Allocates time slots for message exchanges between devices;
• No security responsibilities (apart from access control to the Network).
• External trusted party. Sole source of global trust management.
• Facilitates establishment of public keying material between ordinary devices;
• Facilitates maintenance of public keying relationships;
• Enforces security policy.

NOTE: For discussion’s sake, we assume that the Network Coordinator always performs access control to the Network (not implemented if not needed).

July 2, 2009

René Struik (Certicom Research) Slide 51

RFIDSec 2009

Initial set-up (1)

A B A: x B: y B: y A: x Bootstrap mechanism: non-cryptographic introduction of device with specific role to other device (thus provoking state change from initial state to other state). Pre: Post: (Here, x and y is authentic and/or secret information) Exchange of info:

• Secret info via wire: resurrecting duckling security policy [Stajano, Anderson (1999)]
• Authentic info via limited channel [Smetters et al (2002)]
• 2-way authentic channel, 1-way secret and authentic channel, 2-way secret channel

[ Henk-Jan Hoekman (2004)]

• Proximity-based authentication [Chaum and Brands (1994), etc.]

A B A B

challenge response

July 2, 2009

René Struik (Certicom Research) Slide 52

RFIDSec 2009

Devices and their Roles (2)

Mapping of roles to devices Devices need way to recognize which role(s) other devices play or should play.

• Static mapping. Mapping may be defined at initialization.
• Dynamic mapping. Mapping must be realized by securely associating roles to

devices, allowing dynamic verification. ‘Permanent’ mappings of roles to devices The following mapping of roles to devices are always in effect:

• Each device assumes the role of ordinary device (for all devices);
• The Network coordinator device assumes the role of coordinator (for all Network

devices);

• Each device may assume the role of (alternate) coordinator;
• Each device may assume the role of security manager (for any subset of

devices that include itself).

July 2, 2009

René Struik (Certicom Research) Slide 53

RFIDSec 2009

Operational Description – Set-Theoretic Definition of Roles

Informational elements (provided by device itself) (1) Global device Id. Each device has own static global device Id (IEEE MAC address). (2) Public key (in public-key scenario). Each device has its own public/private key pair (PA, SA). {The public key PA need not to be stored on the device itself.} (3) Access control list (ACL) (if desired). Each device has own set of devices it may wish to establish a secure peer-to-peer link key with. (4) TrustSet (in dynamic-trust scenario). Each device has own set of devices it trusts to assume the role of security manager. (5) CA-Set (in dynamic-trusted party scenario). Each device has own set of devices it trusts to assume the role of trusted third party. (6) ConfigSet (in dynamic configuration manager scenario). Each device has own set of devices it trusts to assume role of configuration manager. (7) ACL-Δ-Set (in dynamic-trust scenario). Each device has own set of devices it trusts to change the ACLSet. (8) Trust-Δ-Set (in dynamic-trust scenario). Each device has own set of devices it trusts to change the TrustSet. (9) CA-Δ-Set (in dynamic trusted party scenario). Each device has own set of devices it trusts to change the CA-Set. (10)Config-Δ-Set (in dynamic configuration manager scenario). Each device has own set of devices it trusts to change the ConfigSet.

July 2, 2009

René Struik (Certicom Research) Slide 54

RFIDSec 2009

The security policy specifies rules that must be adhered to to keep security properties of system invariant, in the event of security events. Discussions are relative to a specific set of Network devices (group). Security events

• 1. Change of group structure.

(a) Exclusion of an old group member from the group:

• Expiration of group membership. Disassociation due to time-out.
• Cancellation of group membership. Disassociation due to cancellation request.
• Denial of access. Disassociation due to enforcement of security policy.

(b) Introduction of a new group member to the group:

• Subscription of the member. Authentication of newly associated device.
• 2. Change of (security relevant) role.

(a) Hand over of coordinator; (b) Changes to list of devices that are trusted as Security Manager for specific device; (c) Changes to list of devices that are trusted as External Trusted Party for specific device; (d) Changes to list of devices in any other role. Simultaneous changes to the group structure and to the security relevant role are conceptually thought of as to occur subsequently (in any order).

Security Policy (1)

July 2, 2009

René Struik (Certicom Research) Slide 55

RFIDSec 2009

• I. Effect of security events - change of group structure

Scenario where information shared between group members is secured via a common (symmetric) group key. Security invariant At any given moment of time, access to information shared between members of a group is restricted to precisely these group members. As such, this includes access to integrity information. Security rule Changes to the group structure shall invoke a change to the common group keys. Rationale 1. This prevents a new group member from gaining access to secured information communicated prior to the moment he obtained access to the key-sharing group.

• 2. This prevents an old group member from gaining access to secured information

communicated after the moment he was denied access to the key-sharing group.

Security Policy (2)

July 2, 2009

René Struik (Certicom Research) Slide 56

RFIDSec 2009

Security rule Changes to the group structure shall invoke a change to the common group keys. This rule can only be enforced if each device takes one of the following two stands:

• Completely rely on the Network Coordinator and on all key generating devices for key-sharing

groups to which he belongs, to provide up-to-date and authentic information on the current group composition. This requires a complete dependency on the key generating devices and

• n the Network Coordinator.
• Maintain up-to-date and authentic information on ‘aliveness’ of devices with whom the device

shares keying material himself. This requires no reliance on the key generating devices, nor on the Network Coordinator. It does, however, require regular re-authentication of all key-sharing devices (the so-called ‘heartbeat’ scenario, where two devices verify each other’s ‘aliveness’). Implementation At any given moment in time (in reality: at regular time intervals), – Each device must re-authenticate with each of its key-sharing parties to obtain ‘aliveness’ guarantees; – Similarly, each device must regularly check that its Security Managers are still ‘alive’.

Towards a Distributed Security Model

July 2, 2009

René Struik (Certicom Research) Slide 57

RFIDSec 2009

Secure Data Transfer

July 2, 2009

René Struik (Certicom Research) Slide 58

RFIDSec 2009

Cryptographic services: data confidentiality, data authentication, non repudiation, replay protection, timeliness. Problems:

• Cryptographic frame protection generally leads to data expansion, due to data

authenticity tag (e.g., up to 16 octets per secured frame).

• Security overhead is substantial (security control info, key identifier, nonce).
• Overhead substantial, esp. if multiple layers of encryption.

Impact: Energy consumption, bandwidth, time latency. Observations:

• Do not send information in full if this information can be reconstructed from info in

the frame and locally maintained side information

• Take cross layer issues into account (multiple layers of encryption)
• Consider purpose of protection (e.g., infrastructure security, content security)
• Exploit open trust model within device

Security Architectural Framework: Data transport (1)

July 2, 2009

René Struik (Certicom Research) Slide 59

RFIDSec 2009

1 1 4 to 20 1 0, 1, 5, or 9 0-4 0, 4, 8, or 16 2

D1

Frame Control Sequence Number Addressing fields Security Control Field Explicit Key Identifier Frame Counter Integrity code (encrypted) FCS Integrity code MFR Payload field MAC payload New MHR MHR n Data Payload (encrypted) Auxiliary security frame header

Frame security dreams (1)

Fields to be authenticated Fields to be authenticated and encrypted Remaining fields

2 1 4 to 20 1 0, 1, 5, or 9 0-4 0, 4, 8, or 16 2

D1

Frame Control Sequence Number Addressing fields Security Control Field Explicit Key Identifier Frame Counter Integrity code (encrypted) FCS Integrity code MFR Payload field MAC payload New MHR MHR n Data Payload (encrypted) Auxiliary security frame header 2 1 4 to 20 1 0, 1, 5, or 9 0-4 0, 4, 8, or 16 2

D1

Frame Control Sequence Number Addressing fields Security Control Field Explicit Key Identifier Frame Counter Integrity code (encrypted) FCS Integrity code MFR Payload field MAC payload New MHR MHR n Data Payload (encrypted) Auxiliary security frame header

No crypto expansion No crypto expansion Reduce Security overhead Reduce MAC header overhead

July 2, 2009

René Struik (Certicom Research) Slide 60

RFIDSec 2009

Frame security dreams (2)

Example: with ZigBee, one may have the following overhead across layers: (ZigBee does not use MAC layer security right now) NWK layer: 22 octets of security overhead APL layer: 12 octets of security overhead Total security overhead: 34 = 22 + 12 octets (this excludes header overhead across layers!) With overhead reduction techniques: – Reduce security and crypto overhead to at most 8 octets in total only – Reduce header overhead significantly Potential gain: much more payload data left for application data (≈50% more) Caveats: This requires augmentation CCM* mode of operation by another construct: – Reuse the AES-128 engine in ‘forward’ mode, as with the CCM* mode – Use binary finite field multiplier, as with the Galois Counter Mode (GCM) {potential performance penalty for long frames in software}

July 2, 2009

René Struik (Certicom Research) Slide 61

RFIDSec 2009

Fields to be authenticated Fields to be authenticated and encrypted Remaining fields

2 1 4 to 20 1 0, 1, 5, or 9 0-4 0, 4, 8, or 16 2

D1

Frame Control Sequence Number Addressing fields Security Control Field Explicit Key Identifier Frame Counter Integrity code (encrypted) FCS Integrity code MFR Payload field MAC payload New MHR MHR n Data Payload (encrypted) Auxiliary security frame header 1 1 4 to 20 1 0, 1, 5, or 9 0-4 0, 4, 8, or 16 2

D1

Frame Control Sequence Number Addressing fields Security Control Field Explicit Key Identifier Frame Counter Integrity code (encrypted) FCS Integrity code MFR Payload field MAC payload New MHR MHR n Data Payload (encrypted) Auxiliary security frame header

Reduce Security overhead Reduce MAC header overhead No frame check sequence

Example

1 with typical payloads

5 7 9 13 6 8 10 14 7 9 11 15 8 10 12 16 9 11 13 17 small +CRC +authenticity MAC payload

July 2, 2009

René Struik (Certicom Research) Slide 62

RFIDSec 2009

1 1 n+3

A1

sFCF Sequence Number ACK payload (encrypted and authenticated) FCS Payload field MFR MAC payload MHR MAC Header

2 1 2 Frame Control Sequence Number FCS MFR MHR

Fields to be authenticated Fields to be authenticated and encrypted Remaining fields

(Idealized case) Further savings: – Crypto: 1 octet1 – FCS: 2 octets2 Total: 3 octets

1 With incorporation of “frame security dream” 2 With removal of CRC-16 FCS

Example – Short ACK protection

July 2, 2009

René Struik (Certicom Research) Slide 63

RFIDSec 2009

Authorization

July 2, 2009

René Struik (Certicom Research) Slide 64

RFIDSec 2009

Security Architectural Framework: Authorization (1)

Authorization and key establishment is based on each of the following: (1) Evidence regarding the true identity of the other device; (2) Evidence whether one wants to communicate with this explicitly identified device. Cryptographic mechanisms: 1. Public-key key establishment mechanism. Derivation of link key between two devices, based on authentic public keys of both parties, including evidence on whom this link key is shared with. 2. Symmetric-key key establishment mechanism. Derivation of link key between two devices, based on secret and authentic pre-shared key between both parties, including evidence on whom this link key is shared with. Non-cryptographic mechanisms:

• Acceptability test. Establishment whether a particular device is to be accepted,

based on a membership test of a so-called Access Control List (ACL).

July 2, 2009

René Struik (Certicom Research) Slide 65

RFIDSec 2009

Security Architectural Framework: Authorization (2a) (public-key scenario)

ACL ACL

ACL Maintenance ACL Maintenance ACL initialization ACL initialization

B

A Authentication, key establishment Wrapped public key info Extracted public key info Wrapped public key info Extracted public key info Public key verification CA key initialization Certificate maintenance Public key verification CA key initialization Certificate maintenance (Link key, A, B) (Link key, A, B)

Notes:

• The authentication protocol establishes a symmetric link key between the devices

(since it is an authenticated key establishment protocol).

• Authenticated key establishment is based on a specific ECC-based protocol, using

manual or implicit certificates.

• Certificate maintenance and ACL maintenance are not discussed any further here.

July 2, 2009

René Struik (Certicom Research) Slide 66

RFIDSec 2009

General protocol format

Key agreement schemes

Step 1: Key contributions Each party randomly generates a short-term (ephemeral) public key pair and communicates the ephemeral public key to the other party (but not the private key). Step 2: Key establishment Each party computes the shared key based on static and ephemeral public keys received from the other party and static and ephemeral private keys it generated itself. Step 3: Key authentication Each party verifies the authenticity of the static key of the

• ther party.

Step 4: Key confirmation Each party evidences possession of the shared key to the

• ther party. This also confirms its true identity to the other

party.

Alice RND X, Certificate A RND Y, Certificate B MAC over messages MAC over messages Bob

July 2, 2009

René Struik (Certicom Research) Slide 67

RFIDSec 2009

Computational aspects

Key agreement schemes

Step 1: Key contributions Each party randomly generates a short-term (ephemeral) public key pair and communicates the ephemeral public key to the other party (but not the private key). Step 2: Key establishment Each party computes the shared key based on static and ephemeral public keys received from the other party and static and ephemeral private keys it generated itself. Step 3: Key authentication Each party verifies the authenticity of the static key of the

• ther party.

Step 4: Key confirmation Each party evidences possession of the shared key to the

• ther party. This also confirms its true identity to the other

party.

Alice RND X, Certificate A RND Y, Certificate B MAC over messages MAC over messages Bob

Offline fixed point multiplication Online variable point multiplication Online verification of public key certificate

July 2, 2009

René Struik (Certicom Research) Slide 68

RFIDSec 2009

Computational Speed-ups

Speed-ups for the following curves: – NIST prime curves, ‘Suite B’ curves, Brainpool curves – NIST random binary curves ECDSA certificate verification + Static ECDH/ECMQV: Speed-up incremental cost ECDSA verify compared to separate approach: 2.4x speed-up (compared to ordinary ECDSA verify) 1.7x (compared to Fast ECDSA verify) Simple side channel resistance virtually for free Other techniques

…

July 2, 2009

René Struik (Certicom Research) Slide 69

RFIDSec 2009

List of Topics (partial!)

July 2, 2009

René Struik (Certicom Research) Slide 70

RFIDSec 2009

Data transport (combined encryption and authentication mode) Use algorithm with parameterize services offered (e.g., decrease penalty of Securing, e.g., small ACKs; distinguish infrastructure security and content security) Allow reuse of keying material across different layers Key transport (key wrap) Provides implicit key authentication and authenticity Is data expansion really necessary? (Authenticity often provided by data transport) Use cases: switch key and wrapped key in same storage (“disk encryption mode”) Entity authentication, public-key key agreement, symmetric-key key agreement Exploit commonalities in protocol flows, state machines, etc. Public-key infrastructure vs. symmetric-key infrastructure Public-key infrastructure often covers “everything under the sun”, but symmetric-key infrastructure is often localized (single trust domain, no CRL, etc.)

Summary of topic areas (1)

July 2, 2009

René Struik (Certicom Research) Slide 71

RFIDSec 2009

Trust models Need for distributed trust models, dynamic “device role models”, and security invariants Certificates Certificate request with inclusion of “key possession” makes mass production of public keys difficult (e.g., production during chip manufacturing) Symmetric-key keying material Key usage, policy, etc. aspects often ignored Specialized issues Efficiency gains by considering computations that have to be performed in groups Example: authenticated key agreement uses certificate verification and key computation Higher layer issues Failure recovery, time synchronization, routing security, fair resource balancing, data aggregation, etc., etc.

Summary of topic areas (2)

July 2, 2009

René Struik (Certicom Research) Slide 72

RFIDSec 2009

Sensor Security – Concluding remarks

Recall our challenge: Bridge the gap between state-of-the-art security that is known and security that is actually being used. Lots of techniques known to address security architectural and trust lifecycle management challenges in all but most mundane environments. Still, hurdles remain:

• support for semi-autonomous lifecycle management (no expensive IT personnel)
• specification of common crypto mechanisms, such as entity authentication, incomplete
• need to take into account constraints of “internet of things”
• need for more involvement crypto/security experts with sensor and control standards

Security constraints

• Decentralized key management
• Flexible configuration and trust model
• Low impact key compromise
• Automatic lifecycle management
• Low communication overhead
• Low implementation cost

Adhoc networks

• No centralized management
• Promiscuous behavior
• Unreliability

Sensor networks

• Low energy consumption
• Low manufacturing cost

July 2, 2009

René Struik (Certicom Research) Slide 73

RFIDSec 2009

Contact info René Struik Phone: +1 (905) 501-6083 Certicom Research Email: rstruik@certicom.com Research interests Core crypto

• ECDSA signatures: speed-up verification (single, batch)
• ECDH key agreement: unbalanced and assisted computations
• Low power crypto, others…

Adhoc sensor networks

• Security models and trust management
• Semi-automatic lifecycle management
• Configuration and installation
• Low implementation cost
• Protocols: re-use building blocks, parallelism flows, etc.
• Keying material: key identification, key usage, key size

Security constraints

• Decentralized key management
• Flexible configuration and trust model
• Low impact key compromise
• Automatic lifecycle management
• Low communication overhead
• Low implementation cost

Adhoc networks

• No centralized management
• Promiscuous behavior
• Unreliability

Sensor networks

• Low energy consumption
• Low manufacturing cost