Outline

Chris Karlof, Naveen Sastry, and David Wagner.

TinySec: A Link Layer Security Architecture for
Wireless Sensor Networks. In ACM SenSys
2004, November 3-5, 2004
Resource consumption attack
Physical tampering attack
Node capture attack
Paper focuses on guaranteeing message authenticity,
integrity and confidentiality
Key: Use the unique deployment aspects of sensor networks to our
advantage

07/30/16

CSE 4/60484: Networked Sensor Systems

page 1

Motivation for link-layer security

Security mechanism in conventional networks, such as
SSH, SSL, or IPSec are end-to-end
Dominant traffic pattern in sensor networks is many-to-one
In-network processing requires intermediate nodes to
process the contents of message
Link-layer security architecture can detect unauthorized
packets when they are first injected into the network

07/30/16

CSE 4/60484: Networked Sensor Systems

page 2

Security risks and threat models

Security risks in sensor networks
Wireless communication is vulnerable to attacks. Adversary
can easily eavesdrop on, intercept, inject, and alter transmitted
data
Adversaries are not restricted by limited resources
Useless packets can be repeatedly sent to drain the nodes
batteries and waste network bandwidth
Sensor nodes can be easily compromised

This paper focuses on message authenticity, integrity, and

confidentiality
Resource consumption attacks, physical tamper resistance,
and node capture attacks are NOT addressed

07/30/16

CSE 4/60484: Networked Sensor Systems

page 3

Design goals for TinySec

Security goals
Access control and message integrity
Confidentiality
Explicit omission: replay protection

Performance
Using cryptography will incur increased overhead in extra
demands on the processor and RAM
The increased message length decreases the throughput and
increase latency, more importantly, it increases the power
consumption

Ease of use
Higher level security protocols will rely on the link-layer security
as a primitive
It should be transparent to applications

07/30/16

CSE 4/60484: Networked Sensor Systems

page 4

Security primitives
Message authentication codes (MAC)
A common solution to achieve message authenticity and
integrity
MAC can be viewed as cryptographically secure
checksum
Generated with a key shared by both sender & receiver
Must be hard to forge without the secret key

Initialization vectors (IV)

For achieving semantic security
IV is a side input to the algorithm to add variation to the
encryption process

07/30/16

CSE 4/60484: Networked Sensor Systems

page 5

Mode of Operation
Block ciphers operate on blocks of plaintext and
ciphertext
Usually 64 bits
A cryptographic mode combines the basic cipher, some
sort of feedback, and some simple operations

Block cipher modes

ECB, CBC, CFB, CTR, OFB

07/30/16

CSE 4/60484: Networked Sensor Systems

page 6

Cipher block chaining mode

The results of the encryption of previous blocks are fed back
into the encryption of the current block.

07/30/16

CSE 4/60484: Networked Sensor Systems

page 7

TinySec design
Existing schemes are inadequate
Well-studied protocols are too heavy-weight for use in
sensor networks
Schemes for cellular telephony, and ad-hoc wireless
networks have serious limitations

Two security options are supported in TinySec

Authenticated encryption (TinySec-AE)
Authentication only (TinySec-Auth)

07/30/16

CSE 4/60484: Networked Sensor Systems

page 8

Encryption
TinySec IV format
Tradeoff between long and short IV
How long is long enough?
Pigeonhole principle and birthday paradox
The structure of IV is dst||AM||l||src||ctr

Encryption schemes
Stream cipher has a devastating failure mode: if the same IV is
ever used, it is often possible to recover both plaintext
Block cipher is preferred
It is as robust as possible in the presence of repeated IV
MAC algorithms use a block cipher and so can reuse code

07/30/16

CSE 4/60484: Networked Sensor Systems

page 9

Why CBC mode

Cipher block chaining mode (CBC) degrades more
gracefully in the presence of repeated IVs
Only the length (in blocks) of the longest shared prefix of
plaintext P and P will be leaked

Modify the CBC mode to be used with a counter as IV

When work with a counter IV, CBC will have occasional
leakage
A simple fix: pre-encrypt the IV
Use ciphertext stealing to avoid message expansion

Block cipher candidates

AES, 3DES, RC5 and Skipjack

07/30/16

CSE 4/60484: Networked Sensor Systems

page 10

Message integrity
Authentication is still necessary even with
encryption
Flip bits in unauthenticated encrypted message can
cause predictable changes in plaintext
Unauthenticated messages are vulnerable to cut-andpaste attack

TinySec always authenticates messages, but

encryption is optional
It uses a cipher block chaining construction, CBC-MAC
for computing and verifying MACs

07/30/16

CSE 4/60484: Networked Sensor Systems

page 11

Packet format

07/30/16

CSE 4/60484: Networked Sensor Systems

page 12

Security analysis
Security of CBC-MAC is directly related to the
length of the MAC
Conventional security protocols use 8- or 16-byte MACs

Is 4-byte MAC safe for sensor networks?

An adversary has a 1 in 232 chances in blindly forging a
MAC
If a forgery will be successful or not can only be
determined on-line
Sending 231 packets on a 19.2kb/s channel would take
over 20 months! It turns to a DoS attack

07/30/16

CSE 4/60484: Networked Sensor Systems

page 13

Security analysis cont

Confidentiality
The security of CBS mode encryption reduces to the length of
the IV (if there is no IV reuse)
TinySec uses an 8-byte IV. However, only 4 bytes are real,
other 4 bytes are borrowed from the existing header fields

Avoid reuse of IVs

Using 4-byte counter is a bad idea
Generating IVs randomly is also a poor choice (birthday
paradox)
IV format in TinySec guarantees that each node can send at
least 216 packets before IV reuse occurs. Namely, no IV reuse
for over 45 days at the data rate of 1 packet per minute

07/30/16

CSE 4/60484: Networked Sensor Systems

page 14

Keying mechanisms
TinySec is not limited to any particular keying
mechanism

07/30/16

CSE 4/60484: Networked Sensor Systems

page 15

Implementation
TinySec was implemented in nesC, the
programming language used for TinyOS
Requires 728 bytes of RAM and 7146 bytes of program
space (256B RAM and 8152B ROM at expense of 6% slower)

TinySec is integrated with TinyOS

Two-priority scheduler is implemented to achieve the
real-time deadline

07/30/16

CSE 4/60484: Networked Sensor Systems

page 16

Evaluation
Two main components to the costs: larger packet sizes when
using TinySec, and the extra computation time and energy
needed for cryptography

07/30/16

CSE 4/60484: Networked Sensor Systems

page 17

Cipher performance

07/30/16

CSE 4/60484: Networked Sensor Systems

page 18

Energy cost

07/30/16

CSE 4/60484: Networked Sensor Systems

page 19

Throughput

07/30/16

CSE 4/60484: Networked Sensor Systems

page 20

Latency

07/30/16

CSE 4/60484: Networked Sensor Systems

page 21

07/30/16

CSE 4/60484: Networked Sensor Systems

page 22