When DarkMatter requested inclusion in the Mozilla trust store, it sparked a big debate about who should arbitrate trust. And that caused me to think about trust in a larger sense. After investigating this issue from many angles, I’ve decided that my word for 2019 is going to be Trust Anchor.
According to NIST, one definition of a Trust Anchor is “A public or symmetric key that is trusted because it is directly built into hardware or software, or securely provisioned via out-of-band means, rather than because it is vouched for by another trusted entity (e.g. in a public key certificate).” It is a really fundamental challenge: whom to fully trust—without having any reference or evidence that the machine is what it claims to be.
Trust is simplified when a machine has an existing identity, for example an X.509 certificate issued by a privately or publicly trusted Certificate Authority (CA). In that case, it is quite easy for machines across the network to validate identities of one another provided that these identities are issued by a trusted CA.
To determine which machine identities to trust, we can rely on existing PKI mechanisms to ensure the identity. In the case where an updated certificate needs to be provisioned, we can be relatively certain that the new certificate is sent to the device which is rightfully entitled to receive it .
But what about machines or devices that do not have an identity yet, but still need one?
This is where Trust Anchors come into play. They provide us with a way to identify or authenticate devices until it is possible to provision them with a legitimate public/private key.
How does this work, you ask? Well, trust anchors come in different shapes and sizes. Let me share a few with you now:
Identifier: SIM card
SIM Cards are the standard for authenticating phone numbers for Telcos. Although not many people realize this, it is the perfect example of a Trust Anchor embedded in hardware. One can buy a new phone, place an existing SIM card in a new phone, and suddenly the new phone is being treated as trusted on the mobile carrier network.
Some hardware vendors also use SIM cards in their devices to prevent unauthorized cloning of their hardware. Although it does not protect the hardware from cloning, a Trust Anchor can prevent the cloned hardware (without a valid SIM card) from running the software as normally expected.
Privileged Access Management (PAM): use an existing third-party trust model.
With this solution the 'currently unknown' machine can receive a certificate, because the solution deploying (provisioning) the certificate will receive a Trust Anchor, most likely a user name combined with a password/token, which can be used to get access to the machine and do the actual deployment.
Credentials/tokens: specific use
Default Credentials/tokens for one-time use may be embedded in an image, with which the new Cluster Nodes/Containers/Applications can request a new certificate. One example of this is embedding a token in a Windows executable or Shell script which can be used for ‘authentication’ while requesting a certificate.
This also applies within DevOps frameworks. For example, Kubernetes expects that all API Communication is encrypted with TLS, so each component that needs to communicate with the API Server will need a certificate. So, when a Component starts (without a valid certificate) it will create a certificate signing request (CSR) and get it signed. During this CSR stage, a limited usage token is used, which is retrieved from a bootstrap file.
As we actively monitor which machines we can trust in our environments, we most often focus on protecting machine identities. That makes perfect sense. Machine identities provide the foundation for securing machine-to-machine connections and communications. But there are also cases where we need to be able to trust machines before their identities have been provisioned. Trust Anchors give us a way to do just that. Hopefully this blog provides you with some insights on Trust Anchors and how to build trust before it can be formally established.
In the meantime, please explore more of our solutions
