Looking back at the last three articles, they more focus on describing the problem and the border condition of security rather than appropriate solutions. Finally, this article will provide some interesting approaches that secure our customers. Some of them are unique solutions by Kontron and S&T, some are also available from other companies as well - but to be honest, there are not many other companies out there that can integrate them as close as S&T.
So let´s start with the basics: Secure Boot and TPM are established mechanism to secure the identity of a device. They specify, which software is allowed to boot the system - typically it’s a Linux or Windows System, that ‘decides’ together with the TPM, if a specific application is allowed to run. In detail, the TPM holds and hides unique IDs or keys that cannot easily be copied, so you can be very sure that a certain information comes from your system. The TPM also helps to create the fingerprints of binaries or applications.
However, the first piece of software that starts to run on a PC, aside of the Management Engine, is typically the Bios. The Secure Boot has several defined storages for publics keys. Depending on these keys, it decides if the OS loader - that typically is initiated after the bio - is valid trusted and therefore allowed to run.
Provide security by offering services on top of pure hardware
Both described functions are valid and used to provide security, but they have to be used the right way. That’s usually where S&T Technologies steps in, by providing services on top of Hardware. In context of the TPM this means, that the TPM chips are correctly initialized and that their public keys are handed over to the customer (that’s how the customer really knows that a device belongs to him). Further, you have to ensure that a dedicates e.g. Linux OS and it´s components will be loaded. For this, an OS and application image, signed with a unique key, is generated for the customer – and that public part is handed over to the Secure Boot mechanism of the bios.
So now, we have a Secure OS (exactly the components we have chosen/without malware) running on our system, but then the trouble with the connected world starts. Whenever a security hole is found somewhere, usually your OS needs an update. This means, the customer has to update the OS. Windows will do the updates for you or also e.g. Canonical is offering some service for LTB versions of certain Linux distributions. But aside of the pure update, our customers need more! They need the confidence that their devices, with their apps on top, are still running after an update.
A fully customizable standard mechanism
How we address that need? Basically, we offer our standard products. A Linux system, based on Yocto, that is frequently penetration tested and gets updates in case they are needed. This is the foundation for all our firewall appliances and remoting solutions. However, our customers often have more very specific needs, so we take several components from that standard products to help them. In the simplest case, this is just one penetration test, so that they know how critical the situation of a product is (of course if a device is never connected, a lot of potential threads are not really a danger). In more complex scenarios, we build and patch their systems over the whole lifecycle.
Of course, this describes a very generic mechanism. We also provide smaller systems with very chip specific mechanisms or sensors, that don’t really have a full operating system or a TPM. Especially in the IoT or sensor environment, we typically provide these devices directly into the cloud installation of our end customers. As a result, they can be sure that a device is really the device they needed, don’t have to touch it themselves and can ship it directly to their end customer or the installation site. So, as you can see, there is a standard mechanism available, which is fully customizable to each customer needs.
How Secure Boot, TPM, Provisioning, Secure OS and “Cloud- Provisioning” work in detail, I will cover within the next post.
{{comment.comment}}