Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security version 3 - overview #1118

Open
fallberg opened this issue Apr 26, 2018 · 0 comments

Comments

Projects
1 participant
@fallberg
Copy link
Contributor

commented Apr 26, 2018

This issue serves as the overview for security version 3 development

It will be updated continuously to cover the various aspects of the design and implementation efforts.

New security scheme will implement obfuscation/security above physical layer (RF specific encryption is not covered by this implementation). This means for routing purposes that only message payload and part of the header will be encrypted.

  • Inclusion mode security

    • ECDH key exchange to establish a NodeKey (unique for each node, GW keeps a table)
    • Blink pattern of NodeKey derivative (hash/crc etc) on node and GW to identify MITM attack
  • Revocation
    TBD

  • Runtime security

    • Node -> Gateway

      1. Node sends unencrypted token request to GW
      2. GW sends random token AES-CCM encrypted with NodeKey to Node (part of token is nonce)
      3. Node decrypts message and use token as key to AES-CCM encrypt message payload.
    • Gateway -> Node

      1. GW sends unencrypted token request to Node
      2. Node sends random token AES-CCM encrypted with NodeKey to GW (part of token is nonce)
      3. GW decrypts message and use token as key to AES-CCM encrypt message payload.
    • Node <-> Node
      Currently not in scope. Nodes are assumed to be resource limited and unsuitable to keep big NodeKey tables.
      It might be feasible to keep a limited fixed size table to hold NodeKeys, but this require some special flow for handling ECDH outside inclusion mode management.

Token will have a TTL counter and a TTL timer at both ends, to allow multiple encrypted messages to be exchanged without a token request for each. Counter and timeout will be user customisable.

  • Device support
    • MAXQ1061 (AES-CCM + ECDH) #1119
    • ATECC508A (ECDH) #1120
    • ATECC608A (ECDH) #1120
    • ATAES132A (AES-CCM) #1121
    • NRF52 (AES-CCM)
    • SW (ECDH)
    • SW (AES-CCM)

Requirements

  • No preshared data required
  • No personalisation required
    • The AT-devices require this, investigate the feasability of doing runtime fixed personalization on demand
  • Automatic device probing and order of preference (optional feature, will require a lot of RAM/flash)
    • Single chip devices has highest priority, pure SW implementation lowest

@fallberg fallberg added this to To do in 3.0.0 via automation Apr 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.