TinySec: A Link Layer Security Architecture for Wireless Sensor Networks

1
TinySec A Link Layer Security Architecture for
Wireless Sensor Networks

• Chris Karlof, Naveen Sastry, David Wagner
• SenSys 2004

2
Motivation

• Sensor networks are more open than even the
  internet anyone nearby can listen or talk to
  your sensors over the air
• Sometimes you dont want all the information to
  be public (for example, inventory control or
  reconnaissance)
• Even if you dont mind others listening, it is
  good to be able to distinguish between your own
  sensors and impostors (who can inject false sense
  data or flood your network with bogus requests).

3
Observations

• Secure communication isnt hard, if we have
  excess network and CPU capacity (eg IPsec, TLS,
  Kerberos, ssh). But sensor networks dont.
• Network overhead is far more important than CPU
  the energy cost for transmitting a single byte
  can be significant.
• Luckily, the very low throughput of sensor
  networks reduces the amount of protection
  required (fewer packets can be collected for
  analysis or replay attacks)
• Secure communication is not security physical or
  DoS attacks are still possible. But we do what we
  can.

4
Types of Protection

• Integrity a message has not been modified during
  transmission.
• Authenticity the message cannot have been sent
  by anyone but the declared sender. This and
  integrity can be provided by a message
  authentication code, typically a one-way,
  collision-resistant hash (MD5 or SHA) of the
  message and a shared secret.
• Confidentiality the message cannot be read by
  anyone but the intended recipient. Encryption
  algorithms such as DES or AES can provide this.
• Encryption does not provide the other two it is
  not necessarily difficult to create a decryptable
  message by splicing together parts of other
  messages.

5
Goals

• Efficiency TinySec should not have noticeable
  impact on message size, latency or processor
  utilization.
• Transparency if it is not painless to deploy, it
  probably wont be used.
• Portability it should run everywhere TinyOS
  runs.
• Open API it should be easy to use TinySec
  components to build higher-level security
  protocols. The end-to-end argument applies.

6
Design

• TinySec provides two transport modes
  authentication (TinySec-Auth) and
  authentication/encryption (TinySec-AE) (cf
  IPsec). As noted earlier, encryption without
  authentication can be insecure.
• TinySec-Auth replaces the TinyOS packet checksum
  with a MAC covering the rest of the packet.
  Authenticated packets are only one byte longer
  than plain packets.
• TinySec-AE is more challenging to implement, due
  to the requirement of an initialization vector.

7
TinySec-AE IV

• Identical messages encrypted under the same key
  produce identical ciphertext. This makes them
  vulnerable to analysis.
• One option would be to rekey after every message
  (cf forward secrecy). But exchanging key
  information consumes too much bandwidth. Both
  sides could apply a function to the last-used
  key, but this would require state for every pair
  of nodes. This consumes too much memory.
• Solution add random data to the message before
  encrypting it, and include that data in plain
  text with the packet. This is an initialization
  vector.

8
TinySec-AE IV 2

• To reduce packet size, a small IV is desirable.
  But the IV is most useful if it doesnt repeat.
  So choosing a good IV requires some thought.
• By the birthday paradox random IVs of length 2n
  can be expected to repeat within 2n/2 packets. In
  effect, this wastes half the bits.
• If all nodes use a counter starting from 0, the
  first packet from each node uses the same IV. For
  some traffic patterns(eg predictable handshaking)
  this can be insecure.
• TinySec constructs the IV from the packet
  metadata (source, destination, type, length) and
  a 2 byte counter, to create more than 216 IVs for
  each pair of nodes.

9
TinySec-AE CBC

• Stream ciphers are fast the key and IV are
  cryptographically stretched to the length of the
  message and then simply XORed with it. The low
  CPU and packet size overhead makes them
  attractive. Unfortunately, they fall to pieces if
  the IV ever repeats. TinySec cant afford an IV
  long enough to prevent IV repetition.
• TinySec uses a block cipher in cipher block
  chaining mode, which degrades more gracefully if
  the IV repeats.

CBC C(Bm) E(K,(((C(B1) ? C(B2)) ? C(B3))... ?
C(Bm-1)) ? Bm)
Stream cipher vulnerability S stretch(K,IV) C
A ? S, D B ? S C ? D A ? S ? S ? B A ? B
10
Is it secure?

• 4 byte MAC means a successful forgery can
  probably be found after 231 attempts.
• To verify the forgery, an attacker must send it
  to a node and see if it is accepted. At 19.2kb/s,
  an attacker can transmit 40 packets/sec, and 231
  packets in 20 months (and fully saturate the
  channel, and drain node batteries).
• Encryption IV reuse may happen after n216
  messages in an n-node network. If sensors
  communicate at low rates as is expected, the IV
  will not repeat for some time (eg at 1
  packet/min, IV repeats in 45 days). If the node
  rekeys before then, IV reuse is no longer a
  danger.

11
Implementation

• 3000 lines of portable nesC code 728 bytes of
  RAM, 7146 bytes of code (and can trade some RAM
  for CPU)
• Hooks into TinyOS radio stack at the byte level
• Crypto has real-time deadline packet must be
  ready by the time the start symbol has been
  transmitted. So TinySec introduces a two-priority
  scheduler to TinyOS, and runs itself at high
  priority.
• Can be trivially added to existing applications
  (using a network-wide key) through a Makefile
  tweak and recompile.

12
Cost

• Raw CPU cost (could be reduced through encryption
  hardware)
• Network cost longer packets mean reduced
  bandwidth, increased latency and energy
  consumption

Energy cost is mostly due to increased packet
size, not crypto
13
Latency

• Longer packets increase latency. It is possible
  that CPU load could too, by delaying non-crypto
  tasks. Experiment with a real application (NEST
  Pursuit-Evasion Midterm Demo Game, 37 nodes)

14
Other security issues

• TinySec only provides link-level protection
  between nodes, not applications. If a node is
  compromised, all data passing through it is too.
  Applications can use TinySec primitives to build
  their own security.
• Sensors are more vulnerable to network attacks,
  but also to physical attacks. If remote snooping
  isnt trivial, just crack open a sensor. Key
  distribution becomes very important for fault
  isolation.
• TinySec doesnt address replay attacks, because
  this requires per-peer state. Applications (with
  better topological knowledge) may be in a better
  position to handle this.

15
Key distribution issues

• A single shared key means one compromised node
  compromises the entire network.
• Periodic rekeying may be necessary to prevent IV
  reuse.
• Pairwise keys require more storage, and prevent
  broadcast and passive listening. Plus,
  distribution is harder.
• In between group keying a set of nodes shares a
  key.
• Work is ongoing. For some applications a key
  distribution server (á la Kerberos) may be
  suitable.

16
Related Work

• GSM, WEP flawed designs provide poor security
  (especially WEP). Other standards are secure, but
  have too much network overhead.
• SNEP unfinished?
• IEEE 802.15.4 similar architecture, but uses a
  stream cipher (and a longer IV). Provides a
  replay protection option.

17
Conclusion

• TinySec provides strong security guarantees at
  the link level, with only moderate cost.
• It is easy to deploy (if we set aside the key
  distribution problem)
• Security is always a trade-off - we spend some
  energy to secure the link, only to find that it
  makes DoS or physical attacks more attractive.
  But with TinySec, the link layer is not the
  weakest link.
• These guys should have designed WEP.