Physical Security

An IoTSF Secure Design Best Practice Guide Article

From the moment of its creation, any physical device is liable to be tampered with in a way not intended by the manufacturer or retailer. IT devices in particular are a target for those people who are just plain curious, hackers seeking a new challenge to their technical skills, people trying to steal corporate knowledge about products & services, those seeking financial gain and a multitude of others pursuing an assortment of malicious intent.

IoT devices are a particular target as they have many features that can be of interest to others:

They can be in private, remote or unattended locations so physical access is almost unrestricted with no time constraints.
Some IoT devices can small in size and therefore easy to conceal if stolen.
Many such devices are technically limited, for example limited processing capability or restricted power supply, which in turn generally means that security measures are similarly limited, potentially making a compromise easier to achieve.
It is often clear by the nature and location of a device that if it were compromised then it could be used to attack a very specific target.
It may be possible that once one device is compromised then a multitude of similar devices could also be compromised more easily.
If multiple devices are compromised then a distributed denial of service attack on another target may be possible.
Compromising an IoT device may give the attacker access further into the IoT network.
Some devices may stay in place for many years. As technology advances, so over time it may become easier to compromise an old device built from out of date technology.

To compromise a device that is right in front of you could try:

Physically opening the device to gain access to its component parts.
Connecting a lead to access a physical port on the device.
Use some form of contactless technology to detect activity emanating from the device, for example electromagnetic radiation, high/low frequency sounds, power supply fluctuations etc.

The key to achieving any of these depends primarily on the very first bullet point, that is to say, having unrestricted access to the device. The more mitigations put in place to protect a device, the longer the time required to compromise it.

How can I protect my devices?

Given the nature of many IoT devices it is impossible to protect against a determined attacker. However there are a range of measures that can be taken to protect against most scenarios and we’ll look at some of those in a moment. When assessing security measures for a device, consider its journey from when it leaves the production line, passes through the distribution chain to retail and then the consumer, then in life and to the end of its life. Various protective techniques can be employed, but the cost model will no doubt be a defining factor as to how much funding is available to mitigate risks. The IoTSF article on Classification of Data talks more about risk assessments, security funding and a company’s risk appetite.

So the first step in protecting a device prior to going into production is to remove all physical, radio or optical ports that were there for development purposes. Of course at least one port is required to connect a production device to the local network or back into the cloud, but all other ports that are no longer required should be removed, including any circuit board tracks that connect the port into the circuitry.

Similarly, all test points should ideally be removed, including pins and circuit tracks, or at least effectively disabling test access by for instance blowing on-chip fuses for JTAG.

If a production device must have some form of administration port, this will be a prime target of attention by attackers. Therefore, logical access to this port must be locked down super tight. To this end the only service running on that port should be the one required to do the administration, all other services must be disabled and unresponsive to probes from scanning tools etc. The administration service must use a secure protocol such as SSH; exposing an insecure protocol such as Telnet on an administration port effectively leaves the device wide open. The management of credentials to access this port must be secure and effectively managed to ensure access cannot be compromised. The IoTSF article on Credential Management talks more about techniques for managing credentials securely.

Chips that manage critical functions are sometimes removed from circuit boards by attackers, so they can connect the chips to test equipment for analysis. To prevent this, key chips can be epoxied to the circuit board or other features such that the chip gets destroyed in the process of removing it. Also, the entire circuitry can be embedded in a block of resin, which will render it entirely inaccessible to all but the most determined.

Of course the last line of defence is the device casing itself. This can provide physical protection to the innards, form part of the mounting assembly and help shield against detection of emanations. One option can be to render the device permanently disabled if the case is opened.

There is always the risk that a device may get tampered with somewhere in the supply chain, perhaps in a warehouse or in transit. Anti-tamper packaging or seals can be applied to give a visual indication of any attempt on interfering with the product.

So there are many ways a device can be protected against malicious acts, but much depends upon usage scenarios, technical capability and particularly on the cost model; that is to say, how much protection can be afforded?

Caveats and Gotchas

The two most obvious ways in to a device are to take its casing apart and access it through any physical ports. For the casing it’s either assume an attacker will get it open, in which case secure the innards, or else make it a robust case. To mitigate against undesired logical access there has to be strong protection at that connection point. A wide range of actions can be taken here and they are discussed in several of the IoTSF Secure Design Best Practice Guides and associated articles.

Good security comes in layers, so good practice at multiple points will bring strong security. Unfortunately though, there is no such thing as perfect security. However should a device become compromised, there may still be opportunity to protect against further misuse of the device via prevention features on the network.

Issues for Consumer Connected Products

Some of the very cheap devices will effectively be un-protectable, on the basis that a device that costs just 50 pence to produce may instead cost £5 with security enhancements in place….all of a sudden the product business model falls apart. So the product owner and the design team need to decide where the trade-offs come.

Further mitigation may be possible from outside the device itself. For instance information supplied to the consumer could help them resolve an issue themselves. Another possibility may be for device monitoring in the cloud to detect undesirable behaviour by the device, and either block it, shut it down, reconfigure it or even force a factory reset.

Questions

So what questions do I need to ask to check if physical security has been implemented?…

Q1: Has a risk assessment been done against the physical security of this product and mitigations put in place to satisfy the company’s management risk appetite?

A1: Yes appropriate mitigations are in place and the implementation has been approved by the company management representatives.

Q2: Are there any identified shortcomings in the physical security mitigations that leave the device still at risk of compromise?

A2: No, we believe all reasonable steps have been taken to physically protect the device.

Q3: Are there any special security considerations that a consumer should be advised of in order to protect their personal details?

A3: (In principle the answer would be No as all security issues have been addressed without further action required by the consumer. In reality though it is likely, and probably good practice, to give advice to the consumer on how to look after their personal data by using strong passwords and other good practice.)

Q4: Has the device been tested by independent professional third party penetration testers to see if they can identify any ways of taking control of the device or extracting data?

A4: Yes it has been independently penetration tested and no Major failings identified (…and here is their covering letter to that effect).

Q5: Were there other non-Major defects found? If so, what is your plan for getting these fixed? Can the fixes be rolled out to devices already in the field?

A5: No there were no other defects found…. or Yes there were X other defects found. All outstanding defects should be fixed in the next Y weeks and can be rolled out as updates as soon as possible thereafter.