TinySec: A Link Layer Security Architecture TinySec: A Link Layer Security Architecture for Wireless Sensor Networksfor Wireless Sensor Networks

Seetha ManickamSeetha Manickam

OverviewOverview

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

MotivationMotivation

• 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 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 NetworksSecurity 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 Motivation for Link layer security in Sensor NetworksSensor 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 Motivation for Link layer security in Sensor NetworksSensor 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 GoalsDesign 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 goalsDesign 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 UseDesign 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 PrimitivesSecurity Primitives

• Message Authentication code

- A cryptographic checksum for checking the message integrity

• Initialization vector (IV)

-A side input to the encryption algorithm.

TINYSEC-DESIGNTINYSEC-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 formatTinysec 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 schemesEncryption 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 integrityMessage 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 FormatTinySec packet Format

Security Analysis of TinySecSecurity Analysis of TinySecMessage Integrity and AuthenticityMessage 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 TinysecConfidentiality 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 TinySecPerformance 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.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 MechanismsKeying 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 TinySecImplementation 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 TinySecPerformance 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 summaryPerformance 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 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?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 SuitesSecurity 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’dCont’d

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

ACL Entry Format

Details of Security SuitesDetails of Security Suites

• NULL – no security, mandatory in all chips

• AES-CTR (Confidentiality alone)– Break plain text into 16-byte blocks p1,…,pn

– Compute cipher text ci = pi xor Ek(xi)

– CTR or Nonce xi is necessary for the receiver to decrypt

NonceNonce• 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 NonceMore 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-MACAES-CBC-MAC

• Sender has options of 4, 8 or 16 byte MAC• Communicating parties have to share a key

AES-CCMAES-CCM

• Applies CBC-MAC over the header and the data

• Encrypts the data• MAC on both using AES-CTR mode

Replay CounterReplay 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.

ProblemsProblems

• Three classes– Nonce management– Key management– Integrity protection

Nonce ProblemsNonce 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 ProblemsNonce 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 ProblemsKey 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 ProblemsKey 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 CounterNonce 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 ProblemsIntegrity 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 ProblemsIntegrity protection Problems

• ACK without MAC– Sequence number sent in clear– Adversary can send ACK’s

ConclusionsConclusions

• 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.

ReferencesReferences

• 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 slidesExtra slides

Take - awayTake - away

• Specification writers– Warn against Dangerous ACL configurations– Better support for various keying models– Do not support AES-CTR– Authenticated ACK

Take - awayTake - 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