Progress Report: Secure Smart Home NFC Setup

Bernd Busse

Supervisor:	Florian Bache
Start Date:	15.03.18
End Date:	12.07.18

# Overview

### Recap: Goal of this thesis

* Employ **NFC** to set up new smart home devices with one's smartphone.
* Develop a protocol to *securely* exchange the required data.
* Proof-of-concept implementation on *Android* and a *Raspberry Pi*.

Note:

---

# Current Progress

### New deadline: *2018-07-12*

More time to finish the protocol and update the implementation.

### NFC reader arrived

Works way better on the Raspberry Pi than the wonky USB-reader.

Note:

### Protocol Goals

1. Securely exchange confidential credentials
    - Encryption
2.  Detect modified messages
    - Signature or MAC
3.  Disallow later re-configuration by different devices
    - Unique configurator ID
    - Hardware reset button
4.  Do not leak data to unsolicited configuration requests
    - User explicitly authorizes configuration (2. step)

Note:

### Protocol Messages

1. *Capabilities Message* (smart home device)

| Type | Length | Purpose |
| --- | --- | --- |
|  sshsp:__V__ | 1B | Protocol Version (0x01 == v0.1) |
|  sshsp:__T__ | 1B | Message Type: __C__ (0x43) |
|  sshsp:__Uuid__ | 16B | Unique Device ID |
|  sshsp:__Cap__ | variable | Device Capabilities |
|  sshsp:__Sig__ | TBD | MAC of this message |

Note:

- Capabilities in a later report

### Protocol Messages

2.  *Configuration Message* (smartphone configurator)

| Type | Length | Purpose |
| --- | --- | --- |
|  sshsp:__V__ | 1B | Protocol Version (0x01 == v0.1) |
|  sshsp:__T__ | 1B | Message Type: __S__ (0x53) |
|  sshsp:__Uuid__ | 16B | Unique Configurator ID |
|  sshsp:__Target__ | 16B | Unique Target ID |
|  sshsp:__Conf__ | variable | Configuration contents |
|  sshsp:__Sig__ | TBD | MAC of this message |

Note:

- Actual configuration values in a later report

### Lightweight Ciphers

* AES-like and SPN
    - LED
    - PRESENT
*  Feistel-like and ARX
    - SIMON and SPECK designed by the NSA for the IoT
    - LEA
    - KATAN

Note:

- SPN = Substitution-Permutation Network
    - *LED*: AES-style rounds, PRESENT S-Box, no key-schedule
    - *PRESENT*: not like AES, hardware oriented
- ARX = Addition Rotation XOR
    - *SIMON* / *SPECK*: by the NSA for the Iot, no security analysis yet
    - *LEA*: software oriented
    - *KATAN*: hardware oriented

### Problems with the key exchange

1. Client *Capabilites* contains plain key
    -  No computing overhead for key derivation
    -  Eavesdropping needs \\(<1\) m distance to read
    -  Extract key before the user configures the device
        -  New random key on every access

Note:

### Problems with the key exchange

2.  (Elliptic-Curve) Diffe-Hellman key exchange
    -  Secure against eavesdropping
    -  Key derivation has more overhead
    -  Fixed public and private-key on device

Note:

---

# Next Steps

### Todo
* Decide on a lightweight cipher to use
* Find a way to *securely* exchange the key
*  Implement protocol wrapper for *Android* and *Dummy*
    - Easily build protocol messages
    - Encryption and MAC primitves
*  Detailed description on attacker models
*  Finish the conclusion chapter

Note:

Thank you for your attention!

Any questions?