Security on Sensor Security on Sensor NetworksNetworks

Security on Sensor Security on Sensor NetworksNetworks

Presented by Min-gyu Cho

SPINS: Security Protocol for Sensor SPINS: Security Protocol for Sensor NetworksNetworks

TinySec: Security for TinyOSTinySec: Security for TinyOS

SPINS: Security Protocol for Sensor SPINS: Security Protocol for Sensor NetworksNetworks

TinySec: Security for TinyOSTinySec: Security for TinyOS

General Security General Security RequirementsRequirements

General Security General Security RequirementsRequirements

• Confidentiality: – The property that information is not made available

or disclosed to unauthorized individuals, entities or processes

• Authentication– The verification of a claimed identity

• Integrity– The assurance that information can only be

accessed or modified by those authorized to do so

Resource ConstraintsResource ConstraintsResource ConstraintsResource Constraints

• Limited energy• Limited computation (4 MHz 8-bit)• Limited memory (512 bytes)• Limited code size (8 Kbytes)

– ~3.5 K base code (“TinyOS” + radio encoder)– Only 4.5 K for application & security

• Limited communication (30 byte packets)• Energy-consuming communication

– 1 byte transmission = 11000 instructions

Asymmetric Cryptography Very Expensive!!!

SPINSSPINSSPINSSPINS

• Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J. D. Tygar, “SPINS: Security Protocols for Sensor Networks,” MOBICOM 2001

• Security Protocols proposed for Sensor Networks which provides– Authentication

• Ensures data integrity & origin• Prevents injecting bogus messages

– Confidentiality• Ensures secrecy of data• Prevents eavesdropping

SPINS: Two ProtocolsSPINS: Two ProtocolsSPINS: Two ProtocolsSPINS: Two Protocols

• SNEP– Sensor-Network Encryption Protocol

– Secures point-to-point communication

TESLA– Micro Timed Efficient Stream Loss-tolerant

Authentication

– Provides broadcast authentication

System AssumptionsSystem AssumptionsSystem AssumptionsSystem Assumptions

• Communication patterns– Frequent node-base station exchanges– Frequent network flooding from base– Node-node interactions infrequent

• Base station– Sufficient memory, power– Shares secret key with each node

• Node– Limited resources, limited trust

SNEP Security GoalsSNEP Security GoalsSNEP Security GoalsSNEP Security Goals

• Secure point-to-point communication– Confidentiality, secrecy

– Authenticity and integrity

– Message freshness to prevent replay

• Why not use existing protocols?– E.g. SSL/TLS, IPSEC

Basic Crypto PrimitivesBasic Crypto PrimitivesBasic Crypto PrimitivesBasic Crypto Primitives

• Code size constraints code reuse

• Only use block cipher encrypt function

– Counter mode encryption

– Cipher-block-chaining message authentication code (MAC)

– Pseudo-Random Generator

SNEP Protocol DetailsSNEP Protocol DetailsSNEP Protocol DetailsSNEP Protocol Details

• A and B share– Keys

• The master secret key χ• derived keys from the master secret key

– Encryption keys: KAB KBA

– MAC keys: K'AB K'BA

– Counters: CA CB

• Counter exchange protocol

A B: CA

B A: CB, MAC(K’BA, CA || CB)

A B: MAC(K’AB, CA || CB)

SNEP Protocol Details (Cont.)SNEP Protocol Details (Cont.)SNEP Protocol Details (Cont.)SNEP Protocol Details (Cont.)

• To send data D, A sends to B:

A B: {D}<KAB, CA>

MAC( K'AB , [CA || {D}<KAB, CA>] )

• To add the freshness for B’s responseA B: NA, RA

B A: {RB}<KBA, CB>

MAC( K‘BA , [NA || CB || {RB}<KBA, CB>] )

• Secrecy & confidentiality– Semantic security against chosen ciphertext attack

(strongest security notion for encryption)

• Authentication

• Replay protection

• Code size: 1.5 Kbytes

• Strong freshness protocol in paper

SNEP PropertiesSNEP PropertiesSNEP PropertiesSNEP Properties

Broadcast AuthenticationBroadcast AuthenticationBroadcast AuthenticationBroadcast Authentication• Broadcast is basic communication mechanism• Sender broadcasts data• Each receiver verifies data origin

Sender

Bob

M

Carol

M

DaveAliceMM

Simple MAC Insecure for BroadcastSimple MAC Insecure for BroadcastSimple MAC Insecure for BroadcastSimple MAC Insecure for Broadcast

Sender

Alice

K

K

M, MAC(K,M)

Bob

K

M, MAC(K,M)

M', MAC(K,M')

TESLA: Authenticated Broadcast TESLA: Authenticated Broadcast TESLA: Authenticated Broadcast TESLA: Authenticated Broadcast

• Uses purely symmetric primitives

• Asymmetry from delayed key disclosure

• Self-authenticating keys

• Requires loose time synchronization

– Use SNEP with strong freshness

TESLA Quick Overview ITESLA Quick Overview ITESLA Quick Overview ITESLA Quick Overview I• Keys disclosed 2 time intervals after use• Receiver knows authentic K3

K4 K5 K6 K7

tTime 4 Time 5 Time 6 Time 7

K3

P2

K5

P1

K3

Authentication of P1: MAC(K5, P1 )

FF

Authenticate K5

Verify MAC

FK6

FK5

TESLA Quick Overview IITESLA Quick Overview IITESLA Quick Overview IITESLA Quick Overview II• Perfect robustness to packet loss

K4 K5 K6 K7

tTime 4 Time 5 Time 6 Time 7

K3

P5

K5

P3

K3

P2

K2

P1

K2

Verify MACs

P4

K4

FF

Authenticate K5

TESLA PropertiesTESLA PropertiesTESLA PropertiesTESLA Properties

• Low overhead (1 MAC)– Communication (same as SNEP)– Computation (~ 2 MAC computations)

• Perfect robustness to packet loss• Independent of number of receivers

TinySec: Security for TinyOSTinySec: Security for TinyOSTinySec: Security for TinyOSTinySec: Security for TinyOS

• Included in TinyOS 1.x• Link layer security mechanism, providing

– Access Control– Integrity– Confidentiality– Transparency to applications and programmers

Block CiphersBlock CiphersBlock CiphersBlock Ciphers

• Pseudorandom permutation (invertible)– DES, RC5, Skipjack, AES – Maps n bits of plaintext to n bits of ciphertext

• Block size n is typically 64 or 128 bits

• Key size k is typically 64 or 128 bits

nKnk

k

E }1,0{}1,0{: }1,0{

Symmetric key encryptionSymmetric key encryptionSymmetric key encryptionSymmetric key encryption• Confidentiality achieved by encryption• Encryption schemes (modes) can be built using block

ciphers– CBC-mode: break a m bit message

into 64 bit chunks (m1,m2,..)– Transmit (c1, c2, …) and iv

iv

m2m1

c1 c2

Ek EkEk

CBC-Mode

• iv is needed to achieve semantic security– A message looks different every

time it is encrypted– iv reuse may leak information

MAC: Message Authentication CodeMAC: Message Authentication CodeMAC: Message Authentication CodeMAC: Message Authentication Code

• Encryption is not enough to ensure message integrity– Receiver cannot detect changes in the ciphertext– Resulting plaintext will still be valid

• Integrity achieved by a message authentication code– A t bit cryptographic checksum with a k bit key from an m bit

message

– Can detect both malicious changes and

random errors– Replaces CRC– Can be built using a block cipher– MAC key should be different

than encryption key

tKm k

}1,0{}1,0{:MAC }1,0{

length

m2m1

MAC

Ek EkEk

CBC-MAC Mode

TinyOS System ChangesTinyOS System ChangesTinyOS System ChangesTinyOS System Changes

MicaHighSpeedRadio

TinySec

CBC-Mode

RC5

CBC-MAC

Packet FormatPacket FormatPacket FormatPacket Format

dest AM IV length data MAC

2 1 4 1 4

Encrypted

MAC’ed

• Key Differences

No CRC -2 bytes

No group ID -1 bytes

MAC +4 bytes

IV +4 bytes• Total: +5 bytes

2 1 1 1

dest AM Grp_ID

length data CRC

2

UsageUsageUsageUsage• Need to be aware of keys & keyfile

– Currently, keys part of program, not intrinsic to mote (similar to moteID)

– Makerules generates a keyfile if none exists and then uses it for programming all motes;

– Keyfiles tied to a particular TinyOS installation. Manual transfer needed to install motes from different computers.

• Only application level code change:– Just use SecureGenericComm instead of GenericComm

• Works on Simulator

AnalysisAnalysisAnalysisAnalysis• Access control and integrity

– Probability of blind MAC forgery 1/232

– Industrial strength is usually 1/264 or less– Replay protection not provided, but can be done better at higher

layers

• Confidentiality– Lots of ways to structure and manage IV’s, but IV reuse will

occur after ~65000 messages from each node– For CBC mode, IV reuse is not as severe has other modes

• Does not necessarily leak plaintext

– Common solution is to increase IV length adds packet overhead