Security on Sensor Networks
description
Transcript of Security on Sensor Networks
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