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)
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