Software Security
Security is hard, expensive, and a requirement for modern devices. Security doesn’t just apply to developer code; it applies to the device boot process and the entire software supply chain, including device management, over-the-air updates, and everything else in between. Considerable energy has been put into the underlying KOS security model so that developers can focus on delivering functionality.
Security in KOS starts with KAB files. Everything from the Linux kernel to Java applications to data files are packaged as KABs. A KAB is a file of files, much like a zip file, that is digitally signed by developer keys and uniquely identified by UUID. Every KAB also has a mode, test, or production based on the keys that were used to sign it. Releases, defined as manifests, are also packaged as KABs. When KOS boots, it uses the manufacturer certificate to verify the manifest and then all referenced KABs in the chain. If any file has been tampered with or doesn’t have the correct authority, the release will be rejected, and the device will roll back to the previous release. KOS has the ability to mount KABs directly into the native Linux filesystem, so the contents of KABs are never extracted; thus, the entire system is completely immutable. KOS provides delegation models to allow 3rd party KABs to be trusted as well as support for chaining manifests which allows external parties to add components to releases in developer-defined ways.
Device Customization
Modern devices need to be tailored to customer needs. Consider a device in a hotel lobby that authenticates using a room key, or a device located at a particular venue that needs themed content. This often goes beyond custom settings and may include custom content or even unique applications per device. Pulling down custom content or apps opens another channel for security concerns, and changing the state of a device in a way that impacts a rollback release can also impact overall stability. To address these needs, KOS provides a feature called chained manifests. While the developer can define a release with a single manifest, that manifest can be provided to upstream tooling, which can add more KABs in a developer-defined way. This doesn’t modify the original manifest, which is digitally signed and immutable; it creates a new manifest KAB that references the original manifest. Using this process, external systems can generate arbitrary chains of manifests that define the entire state of the device in aggregate. A KOS device can evaluate these chains and construct the final device state from the chain.