Authority and Mode
A cornerstone of the KOS security model is the concept of authority and mode, both of which derive from developer keys. Every organization within the KOS ecosystem is assigned a unique authority, which is embedded in the organization’s keys. Similarly, every keyset has an embedded mode, either test or production. As everything in KOS is a KAB file, and every KAB file is signed with developer keys, every component within KOS can be traced back to the originating organization and every KAB is marked as test or production. KOS uses this information at runtime to determine whether to trust software. There are a number of nuances to how authorities and modes are used depending on how devices are configured and how organizations work together. This article delves into these topics to provide insight into how developers can leverage this capability to best match their needs.
Locking Authority versus Mode
A device can be locked in two distinct and independent ways: authority and mode.
In general, when locked to an authority, the device can only boot from a manifest rooted in the locked authority.
When locked in production mode, a device can only use production signed KABs.
While generally accurate, there are some exceptions.
Before getting to the details, let us first examine a few use cases to see how locking impacts the device.
Let’s start with a developer board sitting on the developer’s desk.
This board may be generic hardware that can be used to run software for any number of devices.
If the developer only writes software for their own hardware, the board may be locked to their authority without any issues.
However, if the developer is working as an agency for a manufacturer, they will have a different authority than the manufacturer.
In this case if the board is locked, the developer will not be able to install their software.
In this case it makes sense to leave development boards without an authority lock.
Similarly, if a development board is locked in production mode, the developer must have production keys to test.
As production keys should be restricted access only, developing within locked mode is challenging.
If we consider a production board being installed into a production device however, it would make sense to lock both the authority to that of the manufacturer and the mode to production, so only production signed artifacts can be run.
Vendor versus Manufacturer Authority
A device running KOS works with two different types of authorities: vendor and manufacturer.
An unlocked device has no manufacturer authority while a locked device does.
A device can be locked during manufacturing, after which it will only load a manifest with a matching vendor authority or manufacturer authority.
This check only applies to the first manifest in the chain based on the idea that you may trust an organization to build a software release on your behalf, so trusting their manifest is equivalent to trusting their choices and processes.
A typical developer key contains a single authority, the vendor authority. However, when organizations work together one organization can delegate trust to the other by issuing a delegated key. This is a key based on a cert owned by the issuing organization specifically granting rights to the other organization. When a delegated key is used to sign KABs, the KAB will have a manufacturer authority corresponding to the organization that issued the delegated key and a vendor authority corresponding to the recipient of the delegated key. This allows the recipient to sign KABs that are trusted as if the manufacturer signed them. This will be important in the next section when we examine mode rules.
Test versus Production Signed KABs
While locking the authority of a device controls who can generate a software install, locking the mode controls how the contents of the release must be signed.
As mentioned above, in general, when in production mode, all KABs must be production signed.
However, there is an exception to this rule.
Consider a typical development process where a release candidate is produced and tested.
This should not be production signed as it has not been fully tested.
However, once a given build has been verified, there is complexity in building it again just to production sign it. KOS facilitates this common use case by allowing a production signed manifest to reference test signed KABs only if the KABs match the authority of the device.
For an unlocked device, the authority of the first manifest in the chain is the device authority.
For a locked device, the authority is the manufacturer authority of the device.
Since KOS is an assembly-based operating system, meaning it runs a collection of pre-built KABs instead of requiring a new monolithic build for every release, the tested collection of KABs can be used exactly as-is by simply building a production signed manifest.
It is important to note that any KAB that is not signed by the authority of the device, even while the device is in test mode, must be production signed. This means that any KABs from another organization (unless signed by delegated keys) must be production signed to be used even during testing. Since the most common way of sharing KABs between organizations is using the KOS market, and only production signed KABs can be published to the market, this requirement tends to be easily met.
