Embedded Security

Introduction

In “Embedded Software for the IoT” there is a chapter on security. This is an introduction to the subject of implementing security in an embedded device. Sometimes, however, you need to take an “eagles perspective” to make sure that you got all you need and that your priorities are correct. For these situations it is worth studying the “Security Framework” from IIC – the International Internet Consortium. This organization proposes three “viewpoints”:

  1. Business Viewpoint
  2. Functional Viewpoint
  3. Implementation Viewpoint

In the following we will take a look at these three.

The IIC document can be downloaded here: https://www.iiconsortium.org/IISF.htm

Business Viewpoint

In the business viewpoint, look at the various “Business Contexts” that your product may be used in. Then go a step deeper and look at the “Business Scenarios” for the product. This is like high-level use cases. For each of these you note what is required in terms of the CIA triad: Confidentiality, Integrity and Availability. Also include Authorization.

When the whole exercise (down to Implementation Viewpoint and back) is done, you should for each of these points know which risks there are and how they are treated – e.g.

  • Avoided – e.g. by eliminating the feature that exposes the risk
  • Mitigated by implementing the security that handles the risk
  • Transferred – e.g. by insurance or ensuring the customer takes the risk
  • Accepted – you decide that the risk is well described and acceptable

Functional Viewpoint

Now go a little closer towards the actual implementation. Here there are three layers:

  • Top Layer:
    • EndPoint Protection
      Physical security functions, cyber security techniques and an authoritative identity.
    • Communications & Connectivity Protection
      Authentication and authorization of the traffic. Cryptographic techniques for integrity and confidentiality as well as information flow control techniques protect the communications and connectivity.
    • Security Monitoring & Analysis
      Once endpoints are protected and communications secured, the system state is preserved everything must work through the operational lifecycle.
    • Security Configuration & Management
      Once endpoints are protected and communications secured, the system state must be preserved.
  • Middle layer
    • Data Protection
      Extends from data-at-rest in the endpoints to data-in-motion in the communications. It also encompasses all the data gathered as part of monitoring and analysis function and all the system configuration and management data.
  • Bottom Layer
    • Security Model & Policy
      Governs how security is implemented and the policies that ensure confidentiality, integrity and availability of the system throughout its lifecycle. It orchestrates how all the functional elements work together to deliver cohesive end-to-end security.

You should now be able to draw a block-diagram of your embedded system and note where each of the above comes into play.

Now create a table with all of the above. For each, note the risk and how it is handled in your system (or rather how you plan to handle it) on a conceptual level. E.g. you may decide to have various user-roles, and use SSH etc.

Also note whether the risk is Mitigated, Accepted etc.

Implementation Viewpoint

The IIC Security Framework describes a lot of specific threats like “Intercepts or overrides of the system boot process”, “Vulnerabilities of the Deployment Process” etc. This list is very detailed and will not be repeated here.

For each of the named threats, describe how your solution implements a solution. Now you need to be specific about the use of HW-support, key-storage etc.

From all of the above it is clear that Security is a discipline in itself – and a lot of work. It should also be clear that the sooner you think about security, the better. If you need HW support – e.g. a write-only key-storage with keys used by HW-algorithms – it can be hard to implement later.