1 / 54

1609.1 Security

1609.1 Security. Overview. Devices need to be managed A standard for management messages reduces development and procurement costs SNMPv3 is the natural mechanism but: May be unsuited to constrained devices Does not natively support management of groups

adanna
Download Presentation

1609.1 Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 1609.1 Security

  2. Overview • Devices need to be managed • A standard for management messages reduces development and procurement costs • SNMPv3 is the natural mechanism but: • May be unsuited to constrained devices • Does not natively support management of groups • Does not “natively” support Quiet/Trigger commands for whole device • 1609.1 provides compact management messages, plus group addressing, plus Quiet/Trigger commands • 1609.1 has hooks for security but no explicit security mechanisms • This presentation provides analysis and architecture for security for 1609.1 • Specification of solutions at the next 1609 meeting.

  3. Structure • *** Standard structure slide – check this at the end • Overview of management • Specific security issues • Requirements • Architecture

  4. 1609.1 Device Management

  5. 1609.1 Devices • Examples: • Bridge sensors • Traffic cones • Workmen’s vests • Offline • When in the field, cannot be assumed to have a connection other than via 5.9 GHz • Constrained • May need to be managed from a moving vehicle • May have constrained processors • May not be able to do public-key crypto operations quickly enough to be managed in real time • Battery lifetime • May want to deactivate or sleep remotely

  6. Use case: faulty sensor • Sensor meant to detect icing on bridge is giving incorrect data • Bad messages being sent to traffic from device • It’s winter so it’s not a good time to physically remove the sensor • Might want to do any or all of the following: • Tell warning application to ignore messages from sensor • … if the application is using other sensors • Tell warning application to stop transmitting • … if the device has multiple applications • Tell device to stop sending messages from application • … same as previous but implemented differently • Tell device to stop sending any messages • … if it only has one application but we want to continue getting diagnostics • Tell device to sleep till March • … to save battery

  7. Use case: traffic cones • Initialize in truck on way to site • Bulk initialization: time, ownership, warning message … • Individual initialization: exact location, crypto keying material & certs, …

  8. Use case: daylight savings / speed limit change • Daylight savings: • Congress changes when daylight savings starts / ends, AGAIN • Want to modify any units that display or transmit local time • Speed limit: • Road is improved, speed limit rises • New laws brought in, speed limit goes down • Want to update a series of automatic speed limit notification devices /apps with the new speed limit.

  9. Management activities

  10. Device Lifecycle Set Long-lived Parameters (e.g. owner, security) Manufacture Acquisition Configuration Deployment Operation Core Ops Maintenance Set Short-lived Parameters Administration Redeployment Reconfiguration Resale Decommissioning

  11. Patterns of use Managed Dev • How is management initiated? • Broadcast, groupcast, unicast from field device • Advertisement (initiate session), command (will require ACK), combination? • Assume single NOC. Are there multiple field devices? • Where do management decisions get made? • Live at field device? • If field device is online to NOC, live at NOC? • Pre-recorded at NOC and distributed via field devices? • Combination of the above NOC Field Device Managed Dev Managed Dev

  12. Skilled Field Engineer Managed Dev • Individual sessions with individual devices, or group SET/GET to devices in groups • No need for online connection with NOC. • Initial message may be advertisement or command NOC Field Device Managed Dev Managed Dev

  13. Proxy Managed Dev • Field device proxies communications to NOC • Online connection with NOC. • Sessions initiated at field device, carried on at NOC • Initial advertisement may include an authenticated command NOC Field Device Managed Dev Managed Dev

  14. Preload NOC Field Device Managed Dev • Field device is not online to NOC • NOC preloads commands on to field device • Field device plays commands and records responses • On return to base, field device provides report to NOC Field Device Managed Dev NOC Field Device Managed Dev

  15. Combination Managed Dev • Some commands originate at FD, some at NOC NOC Field Device Managed Dev Managed Dev

  16. Operational Requirements • Identify recipient of command and of response • Commands may be sent to group or to individual managed unit • Combine commands from different originators • Command messages may be proxied • Initiate management to group and continue to manage individual device

  17. Management Protocols • SNMP v3 • Transported over IP (but may be transported over other mechanisms) • Generic access to MIBs • No specific activity commands other than GET/SET variants • Does not specifically address device identification/addressing • No “native” support for locking resources • Supports multiple security models • 1609.1 • Transported over WAVE Management (but could be defined to use other mechanisms) • Access to specific data • Capability GET, Status GET, Configuration GET and SET for 1609 stack related configuration • Additional activity commands: Quiet / Trigger • Defines identity (group and individual) for use in addressing • Locking supported via Change / Detach Manager • Security models TBD

  18. 1609.1 v WSMP • 1609.1 can be thought of as • Management language • Compressed SNMP MIB access commands for specific MIBs • Other activities (quiet/trigger) • Transport protocol specification (identifiers, locking) • Management language is extensible • Any specification that specifies a MIB may also specify a 1609.1-consistent way of accessing that MIB • Specifications may also define values for additional activities • Details of how this would be done are out of scope for this presentation • Session protocol • Implicitly uses concept of sessions (because it restricts to one manager at a time) • Allows session initialization by advertisement / response (via IDs) • Provides anonymizable address (via IDs) • Not designed to support proxying or combining commands

  19. 1609.1 session, no security Manager 1 Remote Session setup (Change Manager Request) (Response) Session Identity Command Operations Request Response Request Response Session teardown (Detach manager approve / deny)

  20. 1609.1 abstract PDU structure Transport – WAVE Management Session – Change / Detach Manager, Session ID Operations – GET/SET, Quiet / Trigger

  21. Security

  22. Threat Model • Want to protect: correct operation of remote devices, information within system, privacy of employees • Airlinkis untrusted • Eavesdroppers, spoofers, replayers • NOC is secure • Remote devices and Manager devices will occasionally be compromised • Trust but verify • Need to be able to identify and remove compromised devices • Eavesdroppers may want to track field engineers or workers with HIA devices on their vests • Privacy

  23. High level security requirements • No spoofing • Commands and responses must be authenticated • No eavesdropping • All messages except first one must be encrypted • … therefore, must be integrity-checked • … and prevent other types of attacks based on e.g. length • Auditability • Commands and responses may be signed • Only signing prevents forgery (non-repudiation) • Parties may specify which commands are signed: SET commands (including Quiet/Trigger) most important, GET responses next most, SET responses and GET commands lowest importance. • Replay protection • Messages must include timestamp, sequence number, or output of sequential function • Privacy • Public identifiers for both parties must be changeable from time to time

  24. Authentication / Authorization • Multiple management roles / privileges • Need granularity in permissions • Privileges = permissions to affect the state of resources • Proof of permissions: • Implicit: manager ID maps to (per-property) ACL • Explicit: manager credential includes statement of permissions, explicitly encoded. • Management devices or users may be temporarily in roles / may be compromised • Management security info itself must be managed • Can introduce new IDs into the system by distributing ACL map with first use of ID

  25. Authentication / authorization, ID + ACL model • Information flow: • Requester presents • Request + • Claimed ID + • Proof of knowledge of a secret linked to that ID • Responder: • Checks proof of knowledge. If it passes… • Uses ACL to confirm that ID has correct permissions for request. If so… • Sends response • Examples of “proof of knowledge”: • ID is in certificate, request is signed by public key in certificate • 1609.2 model • ID is used to reference symmetric key, request is MACed with that symmetric key • 1609.11 model • Authenticated ID + ACL model enables a wide range of permission granting models • From coarse (exclusive device manager access in 1609.1) • To arbitrarily fine (VACM in SNMPv3, see next slide)

  26. Authorization based on SNMPv3 View-based Access Control Model (VACM) (from http://www.tml.tkk.fi/Opinnot/Tik-110.501/1999/papers/management/netsec.html)

  27. Abstract protocol with security Manager 1 Remote Session / security setup Secured on a per-message basis Identify / Authenticate Manager Identify / Authenticate Remote (Request Lock) Session ID (Establish session key for encryption / integrity) Determine which messages shall be signed Operations Request Secured (confidenti-ality and integrity) by the protocol Response Request Response Session teardown Secured by protocol Change Remote ID Release Lock

  28. 1609.1 abstract PDU structure with secure session Transport – WAVE Management Addressing – Session ID Security – Integrity, Confidentiality, Replay, (Authorization, Authentication implicit) Session Management – Manage Locks Signed individual messages (optional) Operations – GET/SET, Quiet / Trigger

  29. Handshake PDUs Manager 1 Remote Auth_M ID_M, *Lock.rq, Signing policy.rq, crypto material, freshness data *session id material, * {Requests} Auth_R, Int_{shared|R} crypto material, (freshness data) Enc_{M|shared| ID_R, *Lock.rsp, *session id material, Signing policy,.rsp, (freshness data,) *{Responses}

  30. Protocol PDUs Manager 1 Remote Int_{M|shared}, Enc_{shared|R} * Signature_M * {Requests} Freshness data Int_{R|shared}, Enc_{shared|M} * Signature_R * {Requests} Freshness data

  31. Protocol PDUs with proxying NOC Manager 1 Remote (some secured session) ID_R (some secured session) Auth_N_R {Requests_N}, Freshness_N Int_{M|shared}, Enc_{shared|R} * Signature_M * {Requests_M}, Freshness_M Auth_N_R {Requests_N}, Freshness_N

  32. End of session • Explicit release or time out on symmetric keys • Explicit release or time out on resource locks • Releasing a key implies releasing the locks that were locked with that key • Symmetric keys can be maintained to reduce overhead in setting up session with known manager • Saves on public key calculations and packet size • Analogous to TLS session resumption • Note that this amounts to using a symmetric key management architecture

  33. Mechanisms

  34. Overview • Initial authentication methods • Symmetric key based • Public key based • Existing candidates for secure session • Everything but “transport” and “addressing” in secured PDU picture • Want to reuse existing technology if possible rather than reinvent the wheel

  35. Symmetric key based authentication • Symmetric key operations are very fast and low bandwidth • Support lots of models – hierarchical keys etc • Performance is a strong motivator to see if symmetric key only systems can be used

  36. Symmetric key based authentication – principles • Managers and remote devices can’t masquerade as NOC • Compromising one manager doesn’t let an attacker masquerade as another • Compromising one remote device doesn’t let an attacker masquerade as another, or as a manager (except to the compromised device) • Compromised manager units must be withdrawn • Ie there must be some mechanism for their keys to expire, be revoked, or be superseded

  37. Symmetric key based authentication – drawbacks • Key distribution and revocation are more complex than for public key if there are offline devices • Managing with expiry appears to require large numbers of keys on managed devices • Managing with revocation is no simpler than PKI version, possibly more complex • Because all secrets in the system are shared, any device that knows a key can masquerade as a different device that knows the same key • (To a first approximation)

  38. Symmetric authentication, one layer of management NOC Remote K_M Initialization: {R_i, K_i = Enc_K_M(R_i) } Operations Request R_i R_i Derive K_i = Enc_K_M(R_i) Operations protected by K_i

  39. Symmetric authentication, trusted management devices NOC Remote Manager K_M Initialization: {R_i, K_i = Enc_K_M(R_i) } Initialization: K_M Operations Request R_i R_i Derive K_i = Enc_K_M(R_i) Operations protected by K_i

  40. Symmetric authentication, compromisable management devices NOC Remote Manager K_M K_U Initialization: {R_i, K_i = Enc_K_M(R_i), K_iU= Enc_K_U(R_i) } Initialization: K_M U for Update Operations Request R_i R_i Derive K_i = Enc_K_M(R_i) Operations protected by K_i Compromise: K_M’ {{K’_i= Enc_K_M’(R_i)} Auth with K_iU} K_M’ Resolve compromise by rekeying all devices: new key to remotes, new master to all trusted managers. Update key stays on NOC

  41. Symmetric authentication, different classes of compromisableMgDevs NOC Remote Manager {K_M}_j K_U Initialization: {R_i, K_i_j= Enc_K_M_j(R_i), K_iU= Enc_K_U(R_i) } Initialization: K_M_c U for Update Operations Request R_i R_i Derive K_i_c= Enc_K_M_c(R_i) Operations protected by K_i_c Compromise: K_M_c’ {{K’_i_d= Enc_K_M_c’(R_i)} Auth with K_iU} K_M_c’ Different classes of manager share the same key Resolve compromise by rekeying all devices: new key to remotes, new master to all trusted managers. Update key stays on NOC.

  42. Scalability / flexibility for symmetric key based authentication • Previous slide assumes “classes” of management devices sharing a key rather than individual keys per management device • Save space on the remote devices • Make it easier to add managers • But difficult to identify misbehaving manager from messages alone • Previous slide assumes a single remote device key for each class of management device • Save space on the remote devices • But means that misbehavior has to be addressed by revocation • Could have a set of device keys, one per time period t, derived from master key K_c_t • Management devices get only the K_c_t for their class and the time period they are expected to be in the field • Don’t need to revoke management devices, just don’t renew a compromised device’s key when it expires  don’t need to reach all potential victims of the compromised device, which could be an expensive process • But this requires an additional factor of #t keys on each managed device – total keys = #c * #t • If we only have a subset of keys on each managed device we’re trading memory cost for update process cost • Symmetric key authentication summary: • Fast operations, low bandwidth • Harder to manage, harder to scale

  43. Symmetric key based authentication • Fast operations and relatively low on bandwidth • Scalability / flexibility issues • Auditability/ non-forgeability issues • Symmetric systems are forgeable – either of the two parties to a communication can claim a message came from the other, even if the first party originated it. • No alternative solution • Privacy can be handled by having handshake contain reference to management class key that evolves over time

  44. Public key based authentication NOC Remote Manager Pub_NOC Initialization: R_i, Pub_NOC Initialization: Cert_M (signed by NOC) Operations Cert_M Check Cert_Misn’t expired or revoked Establish symmetric key K using Cert_M Operations protected by K Compromise: CRL (signed by NOC) … or, just let Cert_M expire

  45. Public key based authentication • Relatively slow operations, relatively high on bandwidth • Better scalability / flexibility issues • Each remote device needs a single root cert belonging to the NOC • The NOC issues Manager devices with certs whose lifetime = expected time on the road of the manager device • May be issues with getting time to managed devices, but relatively inaccurate time is still a big help. • We can handle revocation by expiry without needing large db of keys on the device • Auditability / non-forgeability issues • Asymmetric systems provide non-forgeability – if a message was signed by party X’s key, either X signed it or X has been compromised • Privacy easy to address with short-lived manager certificates • Public key summary: • Slow operations, large bandwidth • But kinder on memory, used correctly, than symmetric key, and easier management.

  46. Authentication mechanisms: recommendation • Support both symmetric and public-key based authentication mechanisms • Continue to research symmetric mechanisms suitable for compromizable management devices • Continue to investigate SNMP security models for a suitable public key based mechanism

  47. Candidate protocols • Existing candidates for secure session • Everything but “transport” and “addressing” in secured PDU picture • Want to reuse existing technology if possible rather than reinvent the wheel • We will focus on SNMP security mechanisms as they are specifically designed for 1609.2 use cases

  48. SNMPv3 Packet format SNMPv3 Packet Format ------------------------- /|\ | msgVersion | | |-----------------------| | | msgID | | |-----------------------| | | msgMaxSize | | |-----------------------| | | msgFlags | scope of |-----------------------| authentication | msgSecurityModel | | |-----------------------| | | | | | msgSecurityParameters | | | | | |-----------------------| | /|\ | | | | | | | | | | | scope of | scopedPDU | | encryption | | | | | | | | | | | | | | \|/ \|/ | | ------------------------- Thanks to http://www.insanum.com/docs/usm.html

  49. SNMPv3 User Security Model • Basic security model to be applied to SNMPv3 packet format

  50. SNMPv3 Packet format – User Security Model (USM) SNMPv3 Packet Format ------------------------- /|\ | msgVersion | | |-----------------------| | | msgID | | |-----------------------| USM Security Parameters | | msgMaxSize | | |-----------------------| /------------------------------- | | msgFlags | / | msgAuthoritativeEngineID | scope of |-----------------------| / |-----------------------------| authentication | msgSecurityModel | / | msgAuthoritativeEngineBoots | | |-----------------------|/ |-----------------------------| | | | | msgAuthoritativeEngineTime | | | msgSecurityParameters | |-----------------------------| | | | | msgUserName | | |-----------------------|\ |-----------------------------| | /|\ | | \ | msgAuthenticationParameters | | | | | \ |-----------------------------| | | | | \ | msgPrivacyParameters | | scope of | scopedPDU | \------------------------------- | encryption | | | | | | | | | | | | | | \|/ \|/ | | ------------------------- Thanks to http://www.insanum.com/docs/usm.html

More Related