A cornerstone of the KOS security model is the concept of authority and mode, 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 several 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 best leverage this capability to match their needs.

Locking Authority vs 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. A device can only use production-signed KABs when locked in production mode. While generally accurate, there are some exceptions.

Before getting to the details, let us 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 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 cannot install the software. In this case, leaving development boards without an authority lock makes sense.

Similarly, the developer must have production keys to test if a development board is locked in production mode. As production keys should be restricted access only, developing within locked mode is challenging.

However, if we consider a production board being installed into a production device, it would make sense to lock both the authority to that of the manufacturer and the mode of production so that only production-signed artifacts can be run.

Vendor vs 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 only loads a manifest with a matching vendor 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 vs 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, all KABs must be production-signed when in production mode. 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 to have 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’s 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. 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 is easily met.