Let's recapitulate: My Enchanted object consists of a sheet of brushed stainless steel with 5 hooks to hang keys. Magnets are used to stick notes to the board. In this blog post I will (try to) design the application as good as possible. Hopefully this can serve as a framework for my (and others) future projects.

User Interface

I'd like to keep the user interface as clean and natural as possible. No additional buttons and no restrictions should be added. The users should be allowed to hang their key on any hook they like and use any free magnet to post messages. The online interface consists of a simple command and return value. Here is a table with the actions a user can do an the effect of that action:

Use Cases

The information provided by the Key Hook Controller (SAMA5D4) alone is of not much use. But combined with other smart home information it can be very useful:

• If nobody is at home turn off the central heating
• If a person signals that it will arrive soon turn it on again
• If the shed key is returned but the shed is not locked send a message
• If the children have not left until 7:00 send an alarm (they will be late for school)
• If a note is removed cross off something of the To-Do list
• …

Normally a smart home controller will be able to take actions like the above. Since my home is not „smart“ I will simulate it with a cloud messaging service and an android app called tasker. This app works like IFTTT – it accepts messages and takes actions. I'll use the SAMA5D4 Xplained Ultra as the controller.

Sensible Data which is Processed

The data we are dealing with is quite personal as it shows a lot about the habits and relation of the people living in the house. The data can be abused in many ways. Most obvious is the use for burglars – they could learn when nobody is at home in order to break in to the house. But with the technology available today much more can be learnt from it. And this data is valuable for corporations and governments alike.

First step into security is to enumerate the data we are dealing with:

From Devices connected to the smart key hooks:

• user identities
• connection information
• passwords
• meta information (date, time, IP address, coarse location, …)

From the smart key hooks:

• Presence Status
• Notes

Now we have established that we need to protect the data from peeping eyes, we'll have a look at how the data is attacked and how we can protect them.

Data flows

The following chapter is a very simple implementation of the Application Threat Modelling from The Open Web Application Security Project (https://www.owasp.org/index.php/Application_Threat_Modeling).

Data is generated by the sensors connected to the controller and sent from the clients over the Internet. The Trust boundary is clearly the Internet connection of the controller.

Threat Modelling

Threat Modelling tries to describe all relevant attacks on the system. It tries to answer the question where and how your data is endangered by the system / application. Here I will use STRIDE to guide me through the process.

This may seem trivial and for a relatively simple application like this it really is, but it will help to make the right decisions later.

From wikipedia:

STRIDE is a system developed by Microsoft for thinking about computer security threats. It provides a mnemonic for security threats in six categories.

The threat categories are:

•     Spoofing of user identity
•     Tampering
•     Repudiation
•     Information disclosure (privacy breach or data leak)
•     Denial of service (D.o.S)
•     Elevation of privilege

So let's jump right into it.

Spoofing of user identity

Users are represented by their key fob which is attached to the key ring. Since users can easily change key fobs / rings technical measures against identity spoofing are not effective. More security would be needed (e. g. PINs / passwords) if rights are attached to key ring identities. On the other hand there is an inherit antipathy of sharing keys even within a family which should be effective against identity spoofing.

Tampering

The program and data is stored in the controller’s flash and RAM which per se is not secure against tampering. Among the security features of the SAMA5D4 is a integrity monitor and a SHA engine. Those can be used to make sure that the content is not changed or to at least to detect changes. Tampering can happen over the network or directly on the hardware by using e. g. the USB ports or removing the flash card. The later is covered by physical security.

Any networked computer is susceptible to “hacking” which can lead to data being changed. To reduce the attack surface the smart key hooks controller does not host any network services. It communicates only with the cloud service to send and receive data.

Malicious clients might send crafted data to corrupt data. Therefore data orginating outside of the trust boundary has to be validated.

Repudiation

The following definition from Wikipedia for Non-Repudiation is relevant to our scenario:

A service that provides proof of the integrity and origin of data

So the threat of Repudiation is to claim that the data is not authentic or is from a different source than claimed. Countermeasures usually require a PKI which is out of scope of this project.

Information disclosure (privacy breach or data leak)

Because of the private nature of the data this the treat which comes into mind first. Of course we do not want our data to be disclosed to any unauthorized party. Not when stored neither when transmitted. End to End Encryption is effective against this attack. One challenge of using encryption is key handling. In this application the user base is small enough to use pre-shared keys without to much disadvantages.

Denial of service (D.o.S)

D.o.S. would be relevant only if we were doing business or some more vital parameters of the house being monitored (like water leakages e. t. c.). Therefore we don't care about this threat here.

Elevation of privilege

Since in a good design all processes have minimal privileges and services delivering information (e. g. web servers) to the untrusted world usually run on least privileges, it's a top priority for a successful attacker to gain additional rights. To protect against this is a difficult task since we will have procedures which need root rights to access the hardware. So I'd try to not let any user data be passed on to procedures with high privileges.

Physical Security

Key hook is inside the house which is trusted for physical security. So no authentication is necessary for interface interaction. The controller board needs to be secured against unauthorized software install. Secure boot and tamper protection can be used for this. Documentation for both features is under NDA so they cant be used in this project. If I can find an other way I'll implement some tamper protection.