Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

Mrinal Wadhwa [Ockam] | Trust and the Internet of Things | InfluxDays Virtual Experience NA 2020

Download to read offline

Mrinal Wadhwa [Ockam] | Trust and the Internet of Things | InfluxDays Virtual Experience NA 2020

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

Mrinal Wadhwa [Ockam] | Trust and the Internet of Things | InfluxDays Virtual Experience NA 2020

  1. 1. Mrinal Wadhwa, Ockam Trust and the Internet of Things
  2. 2. IoT will have an economic impact between $4 trillion and $11 trillion, by 2025. Source: McKinsey & Company
  3. 3. The digitization of the physical world — or the Internet of Things — has opened up tremendous new opportunities, across industries.
  4. 4. • Lower costs: helps detect wastage and identify opportunities to improve efficiency of operations. • Enhanced Safety: prevents accidents, creates a safer environment for employees and reduces damage to assets. • Better Customer Experience: reduces human error, improves quality, provides opportunities to personalize, improves customer satisfaction. • Higher Revenue: new revenue streams from new connected solutions and services.
  5. 5. Source: Microsoft Survey of 3,000 decision makers involved in IoT decisions at enterprise companies from a range of industries • Lower costs: helps detect wastage and identify opportunities to improve efficiency of operations. • Enhanced Safety: prevents accidents, creates a safer environment for employees and reduces damage to assets. • Better Customer Experience: reduces human error, improves quality, provides opportunities to personalize, improves customer satisfaction. • Higher Revenue: new revenue streams from new connected solutions and services.
  6. 6. Unplanned downtime costs industrial manufacturers an estimated $50 billion annually. Source: IndustryWeek & Emerson
  7. 7. IoT-enabled predictive maintenance typically reduces machine downtime by 30 to 50% and increases machine life by 20 to 40%. Source: McKinsey & Company
  8. 8. Source: Microsoft Survey of 3,000 decision makers involved in IoT decisions at enterprise companies from a range of industries There is a large number of such transformative opportunities, across industries.
  9. 9. Internet of Things Edge Computing Cloud ComputingArtificial Intelligence To successfully leverage these opportunities we, typically, require a convergence of technologies • Ability to sense the physical world. • Cheap, low latency ubiquitous connectivity to communicate the sensed data. • Ability to store and analyze large amounts of data. • Algorithms that detect significant events. • Algorithms that learn and improve decision quality using this data. • Systems that automate and make these decisions at the right time. • Ability to actuate decisions in the physical world.
  10. 10. InfluxData platform excels at many of the components needed for this convergence. • IoT data is time series data. • IoT data streams require real-time processing. • Self contained binaries are easy to deploy and manage in edge computing environments. • Telegraf makes it easy to collect from many machine data sources. TICK Stack
  11. 11. Since these use-cases are transformative, they are also usually mission-critical for the business. For our IoT solutions to be adopted, they must be reliable, dependable, trustworthy.
  12. 12. Something is fundamentally wrong. It is too difficult and too expensive to build/maintain secure and private IoT systems. Without security and privacy our IoT solution cannot be reliable, dependable, trustworthy.
  13. 13. An entity should be granted the least amount of privilege necessary to complete its job. Principle of Least Privilege.
  14. 14. The assumption that all systems and traffic within a network boundary can be trusted is flawed.
  15. 15. A lot of people say their Industrial Control Systems are air-gapped but what they mean is they think they are air-gapped. – Andrew Tierney: Pwning an oil rig, DEF CON 27 creativecommons.org/licenses/by/3.0/legalcode youtube.com/watch?v=JoJ6uzIsQNs
  16. 16. 96% share of unprotected industrial control traffic
  17. 17. The assumption that all systems and traffic within a network boundary can be trusted is flawed.
  18. 18. • The network is always assumed to be hostile. • External and internal threats exist on the network at all times. • Network locality is not sufficient for deciding trust in a network. • Every device, user, and network flow is authenticated and authorized. • Policies must be dynamic & calculated from as many sources of data as possible. Zero Trust in network perimeters. A zero trust network is built upon five fundamental assertions:
  19. 19. Security The degree of resistance to encountering an unfortunate event.
  20. 20. Privacy The ability of an individual or group to control the flow of information about themselves.
  21. 21. Trust The willingness of one party to rely on the actions of another party.
  22. 22. Security, Privacy and Trust are application layer concerns. IoT application developers do not have easy to use tools, libraries and infrastructure to granularly control these aspects of their applications.
  23. 23. Open source tools for a device to communicate securely, privately and trustfully with cloud services and other devices. github.com/ockam-network/ockam
  24. 24. The ability to move messages through a variety of IoT topologies. Ockam
  25. 25. In a zero trust network, since there is no implicit trust in network boundaries trust must be based on the identification, authentication and authorization of the sender of a message. Trust must be rooted in: Machine Identity
  26. 26. The ability to safely generate, store and use unique cryptographic keys. Ockam
  27. 27. In a zero trust network, all packets received on the network are immediately suspicious. Strong cryptographic primitives must be used to validate that a message was not tampered en-route. All messages received on the network must be checked for integrity. Since the identity of the sender of a message is perceived from the contents of a message without a data integrity guarantee we have nothing and are forced to place trust in the network boundary.
  28. 28. Ockam
  29. 29. Initiator Responder Shared Secret Shared Secret M1 M2 M3 The entities involved use Public Key Cryptography to authenticate each other and agree on a shared secret. Authenticated Key Exchange
  30. 30. Initiator Responder Shared Secret Shared Secret M1 M2 M3 The shared secret is then used as a key in Symmetric Key Cryptography to maintain confidentiality and integrity of application data. Application Data - Authenticated Encryption The entities involved use Public Key Cryptography to authenticate each other and agree on a shared secret. Authenticated Key Exchange D
  31. 31. Encrypting a message on a device before transmitting it on the network limits the exposure of that information to the trustworthiness of the sender and the intended receiver of the message. End-to-end encryption. This is how we can apply the principle of least privilege.
  32. 32. Ockam
  33. 33. Ockam
  34. 34. Ockam
  35. 35. Ockam Libraries: • Rust • C • Elixir Ockam Add-Ons: • Telegraf as an ExecD plugin • InfluxDB • Golang • JavaScript/TypeScript • Swift • Kotlin/Java • Kafka
  36. 36. Let’s see how Ockam can help in typical deployments that combine InfluxData platform and IoT …
  37. 37. InfluxDB / InfluxDB Cloud Telegraf Improved logistics with connected trucks.
  38. 38. Influx has two builtin security mechanisms
  39. 39. Server-Only Authentication If a signed certificate is configured, a truck can establish trust that it is talking to the intended instance of InfluxDB.
  40. 40. Let’s dig into how this trust in the InfluxDB server’s identity is established: The device on the truck has a root trust store.
  41. 41. Let’s dig into how this trust in the InfluxDB server’s identity is established: The device on the truck has a root trust store. Typically, on Linux machines, this is the Mozilla Firefox browsers root store. This has 148 trusted parties. These 148 parties are free to create subordinate trusted parties, there are 1000s of trusted parties.
  42. 42. If the defaults are followed any one of these 1000s of parties could issue a seemingly valid certificate that a truck would believe is about the intended InfluxDB server. Major certificate authority breaches happen. Spoofed Server Identity feistyduck.com/ssl-tls-and-pki-history
  43. 43. This trust model is okay for web browsers because they have to trust lots of websites and they run complex infrastructure to identify breaches and manage revocation.
  44. 44. IoT devices shouldn’t base their trust in the WebPKI. There should instead be an application controlled public key infrastructure that manages key lifecycle, revocation and pinned chains of trust. Ockam
  45. 45. Influx has two builtin security mechanisms
  46. 46. Influx Tokens Allows us to granularly control which measurements can be reported by an entity that presents a specific token. A sensor in truck one should only report measurements for truck one. A pressure sensor should only report pressure.
  47. 47. In practice this presents some complex challenges for IoT systems:
  48. 48. Unique Tokens • If we have 100000 trucks, we must somehow generate and deliver a unique token to each truck. If the token is not unique, truck one could report about truck two - spoofed truck identity. If the token is not unique, someone can steal one token and create millions of fake trucks - sybil attack.
  49. 49. Storage: • Authentication/Identity secrets should be hard to steal.
  50. 50. Revocation: • If we suspect that a token has been compromised we need some way to revoke that token and issue a new token. We can’t render a truck unusable in the field. Manually visiting a truck would be very costly.
  51. 51. Rotation: • We need some way to frequently rotate tokens in order to reduce the likely hood of a compromise. Manually visiting all 100000 trucks would be very costly.
  52. 52. InfluxDB / InfluxDB Cloud Telegraf Improved logistics with connected trucks.
  53. 53. InfluxDB / InfluxDB Cloud Telegraf + OckamD (ExecD plugin) Ockam Influx Add-On in a Sidecar Ockam with Influx
  54. 54. Ockam as an ExecD plugin for Telegraf
  55. 55. Each truck can now have unique identity keys that are stored safely in hardware and cannot be easily stolen. Private keys never leave the secure environment.
  56. 56. Each truck is communicating over a secure channel that is: • Mutually Authenticated • Guarantees Data Integrity • Guarantees Confidentiality • End-to-end encrypted • Lightweight • Friendly to occasionally connected devices • Provides Forward Secrecy, Key Compromise Impersonation protection etc.
  57. 57. The identity keys of the trucks have managed lifecycle - they can be rotated and revoked based one simple policies.
  58. 58. InfluxDB / InfluxDB Cloud Telegraf + OckamD (ExecD plugin) Ockam Influx Add-On in a Sidecar The Ockam Influx Add-On integrates with InfluxDB API to get granular, short-lived, unique authorization tokens and leases them to precisely control which devices are authorized to report which measurements.
  59. 59. Bootstrap/Enrollment
  60. 60. InfluxDB / InfluxDB Cloud
  61. 61. InfluxDB / InfluxDB Cloud Pre-key Bundle
  62. 62. InfluxDB / InfluxDB Cloud Pre-key Bundle
  63. 63. InfluxDB / InfluxDB Cloud Ockam Enrollment Protocol: Based on Extended Triple Diffie-Hellman or X3DH to asynchronously bootstrap a mutually authenticated secure channel. Mutually authenticated, end-to-end encrypted, secure channel
  64. 64. Future protocols like enrollment: • Secure Software Updates • Find a lost device
  65. 65. InfluxDB / InfluxDB CloudGateway LPWAN UDP End-to-end Encrypted Secure Channels
  66. 66. End-to-end Encrypted Secure Channels
  67. 67. End-to-end Encrypted Secure Channels
  68. 68. InfluxDB / InfluxDB CloudInfluxDB Edge
  69. 69. pentestpartners.com/security-blog/super-systemic-iot-flaws/
  70. 70. Ockam
  71. 71. Ockam Libraries: • Rust • C • Elixir Ockam Add-Ons: • Telegraf as an ExecD plugin • InfluxDB • Golang • JavaScript/TypeScript • Swift • Kotlin/Java • Kafka
  72. 72. The end result - dependable data in your InfluxDB.
  73. 73. github.com/ockam-network/ockam Mrinal Wadhwa twitter.com/mrinal CTO, Ockam

Mrinal Wadhwa [Ockam] | Trust and the Internet of Things | InfluxDays Virtual Experience NA 2020

Views

Total views

179

On Slideshare

0

From embeds

0

Number of embeds

0

Actions

Downloads

1

Shares

0

Comments

0

Likes

0

×