RE: IoT Security - Certitude Digital

I am formulating a response to this, and will discuss within the Chairs.
Michael McCool

From: Santusht Perera [mailto:santusht1962@gmail.com]
Sent: Thursday, August 24, 2017 07:30
To: public-wot-wg@w3.org
Subject: IoT Security - Certitude Digital

Dear W3C,

I was wondering if you and the Web of Things Interest Group would be interested in learning about Certitude Digital’s (www.certitudedigital.com<http://www.certitudedigital.com>) unique approach to protecting digital assets. A drawback of traditional cybersecurity protection is its emphasis on protecting containers (e.g. file systems, servers, and the cloud) which result in large “attack surfaces” for hackers to target. Once a container solution is breached, all its files or digital assets are freely exposed. The larger the container, the greater the incentive.

Certitude Digital’s AMULET™ ecosystem differs from conventional cybersecurity methods in that it protects individual digital assets. An AMULET™ protected file stores up to twenty-one (21) environmental criteria that must be met in order to invoke a file. Digital assets are only unprotected for brief periods of use, and no version of the unprotected file persist in any form. By protecting individual digital assets, AMULET™ technology narrows a hacker’s attack vector to a single file. Further security can be achieved by layering AMULET™ protection thus requiring multiple, unique hacks to gain access to a single digital asset.
There are a variety of ways that AMULETs could be deployed to support access to any digital asset in an IoT system, including within the gateway APIs and interfaces themselves. “Digital assets” include an action or event represented by the code raising or responding to an action. AMULETs could augment access to the gateway's API and web interface where the JSON Web Tokens reside now.
From the perspective of the developer, AMULET system would simply provide yes/no gating. The author, owner, or controller of the asset being secured would designate the appropriate AMULET criteria to be queried in order to supply the yes/no response at the decision point. So the only support needed at the gateway is to ask for access and abide by the yes/no answer – that is, add a LeaseRequest() for the assigned AMULET at that point.  AMULETs could exist alongside JSON Web Tokens code or other web services, making the AMULET services plug-in additive or optional.
Describing the implementation establishes the necessary “fork in the road”. Our solution does several things to directly address issues germane to IoT, and especially “Web of Things”.

  1.  To begin with, AMULETs and their framework have an intimate relationship with the host device, whereas the Web of Things involves relationships between connected things – the two are by definition complementary. This means the AMULET framework can supply to trusted components absolutely reliable information about the validated logged-on user independent of any representations made by a user or application (or hacker acting in their stead). User actions can include: running applications, services, memory, O/S, storage, GPS location, sensor data, connections, file contents, devices, Internet/Ethernet/Bluetooth assets accessible from the device, O/S-reported states, operational hysteresis, and display images among other things.
  2.  The AMULET framework independently validates, in real time, any and all environmental elements in which the AMULET criteria has registered an interest, relieving the client of an AMULET of all of those burdens;
  3.  The AMULET itself is an independent, abstracted encapsulation of all the questions a client might want to ask of a host device’s environment prior to any instance of access to that host device or any of its resources, as described above. This list of questions, which we call “criteria”, are framed as “yes/no” questions, and can contain as few or as many questions about the environment as desired. Because each individual question extracts a yes/no answer, the aggregated concatenation of all questions in a criteria set, no matter how many or how few, are guaranteed to produce a singular yes/no response to the question “Are all listed criteria is the AMULET satisfied?” at the moment of invocation of the request, yes/no;
  4.  The AMULET criteria are securely dynamic, subject to change in real time at any time by the authorized owner, author, controller or the AMULET. This means no client code needs to be recompiled and/or updated to accommodate changes or even extensions of capabilities;
  5.  AMULET criteria sets can be aggregated, dynamically or at digital asset enciphering, so that multiple AMULET criteria sets can be used in response to a given instance-of-access request to combine the interests and concerns of multiple stakeholders. They can be nested and chained to provide sophisticated parent-child governance, or for extremely fast (the actual criteria conditions are pre-assessed by background threads, so the actual answers to yes/no question is immediate) execution of if-then-else programming constructs based on the host device’s current environment.
So, in the case where JSON Web Tokens make resource access decisions based on pre-coded decision points at the web services themselves, or rely on fixed points of information supplied (perhaps unreliably) over-the-wire by hardcoded device software, AMULET technology provides a dynamic and flexible framework to protect these decisions. Here we’ve presented AMULETs only from the perspective of a host IoT device. AMULETs and the AMULET framework could also be installed at the webservice/website host, or at any service provider, to gate, monitor, and safeguard inter-service activities and assets (these would be consistent with traditional AMULET server deployments).

Let me know if anybody in the group would like to learn more,

Tom