for Wireless Sensor Networks

slurpslapoutΔίκτυα και Επικοινωνίες

20 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

87 εμφανίσεις

TinySec: A Link Layer Security Architecture
for Wireless Sensor Networks

Seetha Manickam

Overview


Motivation


TinySec
-
Introduction


Sensor Networks
Security threats and
Need for link layer
security architecture
design


Design goals


Tiny sec Design




Security Analysis of
Tinysec


Performance
Evaluation of Tiny
Sec


Security flaws
identified in 802.15.4
standard for sensor
networks

Motivation


Sensor networks : Resource constraint
networks


small memories, weak
processors, limited energy…


Conventional security protocols (802.11b ,
802.15.4 are found to be insecure , adds
lot of overhead (16
-
32 bytes) )


Need for a new security architecture for
sensor networks
-
TINYSEC

TINYSEC


Light weight and efficient link layer
security package


Developers can easily integrate into
sensor network applications.


A research platform that is easily
extensible and has been incorporated into
higher level protocols.

Security threats in Sensor Networks


Use of wireless communications
-
In a broadcast
medium, adversaries can easily eavesdrop on, intercept,
inject and alter transmitted data.


Adversaries can Interact with networks from a distance
by inexpensive radio transceivers and powerful
workstations.


Resource consumption attacks. Adversaries can
repeatedly send packets to drain nodes battery and
waste network bandwidth, can steal nodes.


However , these threats are not addressed. Focus is on
guaranteeing message authenticity, integrity and
confidentiality

Motivation for Link layer security in
Sensor Networks



End
-
End security Mechanisms : Suitable only for
conventional networks using end
-
end communications
where intermediate routers only need to view the
message headers.


BUT, in Sensor networks In
-
network processing is done
to avoid redundant messages
-
Requires intermediate
nodes to have access to whole message packets and
just not the headers as in conventional networks.


..contd..


Motivation for Link layer security in
Sensor Networks


Why end
-
end security mechanisms not suitable
for sensor networks?


If message integrity checked only at the
destination, the networks may route packets
injected by an adversary many hops before they
are detected. This will waste precious energy.


A link layer security mechanism can detect
unauthorized packets when they are first
injected onto the network.

Design Goals
-
Security Goals


A link layer security protocol should satisfy three
basic security properties:


Access control and Message integrity


-
prevent unauthorized parties from participating


Confidentiality


-

keeping information secret form unauthorized parties


Explicit omission: Replay protection


-
an adversary eavesdropping a legitimate message sent b/w 2
authorized parties ..replays it at a some time later

Design goals

Performance goals


A system using cryptography will incur
increased overhead in length of the
message .


Overhead limitations
-
REQUIRED


Increased message length results
-


-
decreased message throughput
-
increased latency


-
INCREASED POWER CONSUMPTION (
Sensor Networks

)

Design Goals
-
Ease of Use


Security Platform
-

Higher level security protocols
can use Tinysec to create secure pair wise
communication between neighboring nodes.


Transparency
-

Should be transparent to the user


Portability
-

should fit into the radio stack so that
porting the radio stack from one platform to
another is a simple job.




Security Primitives


Message Authentication code


-

A cryptographic checksum for checking
the message integrity


Initialization vector (IV)


-
A side input to the encryption algorithm.





TINYSEC
-
DESIGN


2 Security Options
-

1.Authentication
Encryption ( Tinysec
-
AE) 2. Authentication
only (Tinysec
-
Au)


Encryption :



Specifying the IV format



Selecting an encryption Scheme


Tinysec IV format


IV too long
-

add
unnecessary bits to the
packet


Too short


Risk of
repetition


How long should be the
IV? N bit IV repeat after
2^n +1. If we use a n bit
counter repetitions will
not happen before that
point.


Encryption schemes


CBC is the most appropriate scheme for sensor
networks

why?


Works better with repeated IVs.


IVs can be pre encrypted for use since it is
proved that CBS mode is highly secure with non
repeated IVS.


One drawback
-

Message expansion



Use Cipher text stealing
-
Cipher text
length=plaintext length




Message integrity


Authentication is very Important in Sensor
networks ( Encryption is optional, though!)


Confidentiality is only necessary when
something needs to be kept secret.


Consider the case of burglar alarm
-
Encryption is unnecessary for an alarm
signal, but it is undesirable to have it from
an adversary.

TinySec packet Format

Security Analysis of TinySec

Message Integrity and Authenticity


Security of CBC
-
MAC is proportional to the length of the
MAC.



Is the choice of 4 byte MAC
-

less secure then?


NO!!!!!
..Not for sensor networks!



Given 4 byte MAC
-

adversary should make at least 2^31
tries. Even if the adversary flood the channel, he can
send only 40 forgery attempts/sec, sending 2^31 would
take 20 months. Battery operated nodes do not have that
much energy to collect all those packets.

Confidentiality analysis for Tinysec


Combination of carefully formatted IVs ,
low data rates and CBC mode for
encryption achieves high confidentiality in
TinySec.


The format of the last 4 bytes

maximizes
the number of packets each node can
send before there is a repetition of IV.


For a network of n nodes, n.2^16 packets
will be sent before the reuse of IV.

Performance Evaluation of TinySec


Increases the computation costs and the
energy cost of sending a packet, but these
costs must be modest compared to the
security that Tinysec provides.


Keying mechanism

contd.


Use per
-
link keying, separate Tinysec key
for each pair of node wishing to
communicate. Drawback: Key distribution
becomes a challenge.


Allow a group of nodes to share a TinySec
key rather than each pairs. Group keying
provides an intermediate level of
resilience.


Keying Mechanisms


Appropriate keying mechanism for a
particular network depends on several
factors.



Tinysec key
-

A pair of skipjack key
-
one
for authentication, one or encryption.


Simplest keying mechanism: Use a single
key for the entire network, Preload the key
before deployment.
-
Adversary can
compromise on node and get the key..



Implementation of TinySec


Implemented on Berkeley sensor nodes.


Integrated into TOSSIM simulator.


3000 lines of nesC code.


TinyOS 1.1.2 radio stack modified to
incorporate TinySec.


Level of protection can be included in the
data payload.


Performance Evaluation of TinySec


Increases the computation costs and the
energy cost of sending a packet, but these
costs must be modest compared to the
security that Tinysec provides.


Performance summary


The energy, bandwidth and latency
overhead

all are less than 10% by using
Tinysec.


Overhead
-
due to the increased packet
size for cryptography.


Tinysec is very competitive with other
solutions.


Tinysec has gathered a number of
external users.


Insecurity of 802.15.4


Where is Security in 802.15.4 ?


Handled by the Media access control layer


The application controls the security required


By default


“NO Security”


Four types of packets


Beacon, Data, ACK, Control packets for MAC Layer


NO Security for ACK packets


The other packets can optionally use encryption
or integrity checks

How does it work?


Application decides the choices on the security
level. (A bool value)


Access Control Lists are used to enforce these
security levels (max up to 255 entries)


If security is enforced then the MAC layer looks
up the ACL table for the cryptographic material
for the destination



Security Suites


No security


NULL


AES
-
CTR
-

Encryption only, CTR Mode


AES
-
CBC
-
MAC


MAC only (options of 32bit,
64bit and 128bit MAC’s)


AES
-
CCM


Encryption and MAC (options of
32bit, 64bit and 128bit MAC’s)


Replay protection can be turned on or off for any
of the above

Cont’d


On packet reception, based on the flags
the MAC layer decides how to process the
packet


ACL Entry Format

Details of Security Suites


NULL


no security, mandatory in all chips


AES
-
CTR (Confidentiality alone)


Break plain text into 16
-
byte blocks
p
1
,…,p
n


Compute cipher text
c
i

= p
i

xor E
k
(x
i
)


CTR or Nonce x
i

is necessary for the receiver
to decrypt

Nonce


Is made up of


Static flags field


Sender’s address


3 counters


4 byte frame counter (identifies the packet)


1 byte key counter


2 byte block counter (numbers the 16 byte blocks
in a packet)



More on Nonce


Frame counter controlled by the hardware radio


Sender increments it after every packet


When reaches max value no further encryptions are
possible


Key counter


application’s control


Used when frame counter has reached its max value


Goal of frame and key counter is to prevent nonce reuse
(in a single key’s life
-
time)


Use of block counter


ensure different nonce’s are used for each block


need not be transmitted

AES
-
CBC
-
MAC


Sender has options of 4, 8 or 16 byte MAC


Communicating parties have to share a key

AES
-
CCM


Applies CBC
-
MAC over the header and the
data


Encrypts the data


MAC on both using AES
-
CTR mode

Replay Counter


Applicable to AES
-
CTR and AES
-
CCM
suites


The replay counter is 5 bytes long


Frame counter


Key Counter (MSB)


Note: This is same as the nonce but is
used for a different purpose.

Problems


Three classes


Nonce management


Key management


Integrity protection

Nonce Problems


Same Key in Multiple ACL entries


If used, very likely that nonce is also reused


This could break the confidentiality


Simple solution


If using the same key then use only one ACL entry,
after sending the first packet, change the ACL entry
(the software must keep track of which destinations
are in play)

Nonce Problems


Loss of ACL


Power Failure


Assuming that the ACL is restored, what about the
nonces?


The authors say that the 802.15.4 lacks clarity in this
issue


Recommendation


re
-
key after power failure


Related issue


what happens when the node is
sleeping


Again there is presumably no clarity in the
specification


Key Management Problems


No group keying


First approach: Assign different ACL entries for all the
nodes in the group and use the same key (Nonce
management problem, ACL will be large)


Second approach: Single ACL entry


heavy, since
for every destination the ACL has to be changed.
Assuming the receivers also employ the same
strategy then the receiver must switch the ACL before
a packet arrives from a destination other than that in
the current ACL

Key Management Problems


Replay protection is incompatible with
group keying


Node x transmits 100 messages, so replay
counter is at 99 now


Node y starts transmission, its replay counter
is going to 0, so the packets are dropped.

Nonce and Replay Counter


Nonce is bound to the key


incremented
with every message that is sent should
use a different nonce (if two different
entries use the same key, they share a
nonce)


Replay counter is bound to the sender’s
address. If two ACL entries share a key,
they still have different replay counters.

Integrity protection Problems


Unauthenticated encryption


Recommendation


do not use AES
-
CTR


DoS on AES
-
CTR


Two parties X and Y communicating (Replay
protection is enabled)


Attacker sends a very high value for the key and
frame counter with garbage with sender ID X


This would cause the messages from legitimate
sender to be dropped.

Integrity protection Problems


ACK without MAC


Sequence number sent in clear


Adversary can send ACK’s


Conclusions


We have learnt that there are design
vulnerabilities in the conventional
protocols for sensor networks.


Conventional protocols tend to be
conservative in their security guarantees,
typically adding 16
-
32 bytes of overhead.


Tinysec addresses these with extreme
careful design and takes advantages of
the limitations of sensor networks.

References


Chris karlof, Naveen Sastry, David Wagner,”TinySec: A Link Layer
Security Architecture for Wireless Sensor Networks,” Proceedings of
the 2nd international conference on Embedded networked sensor
networks, p
-
162
-
175, 2004


Naveen Sastry and David Wagner, “Security Considerations for
IEEE 802.15.4 Networks”. ACM Workshop on Wireless Security
WiSe 2004, October 2004




Extra slides


Take
-

away


Specification writers


Warn against Dangerous ACL configurations


Better support for various keying models


Do not support AES
-
CTR


Authenticated ACK

Take
-

away


Application Designers


Do not use AES
-
CTR


Do not rely on ACK


Hardware Designers


Support for 255 ACL entries (depends on the size of
the network)


Retail ACL in low power mode (if possible nonces
too)


Do not support AES
-
CTR