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.
What is a Trust Anchor - and why does it matter?
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.
TLS Machine Identity Management for Dummies
But what about machines or devices that do not have an identity yet, but still need one?
- How can we be confident that a new device requesting a certificate (and the key pair belonging to it) for a global commerce website is actually a new Load Balancer, for example, and not a rogue Raspberry Pi installed by an attacker?
- Or what about new payment terminals being installed across the country? At installation time these machines may be without an identity, but they will certainly need certificates before they can operate. How can we be sure that we are globally activating only ‘real’ devices?
- Or maybe we need to protect patented hardware so that cheap clones are not able to run expensive, proprietary software.
- Or we have 'applications' in the cloud that need to communicate back to the mothership. Only authorized applications should be able to connect, but how can we control the identity of those applications/containers if they ‘live’ in the cloud?
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.
Get a 30 Day Free Trial of TLS Protect Cloud, Foolproof Certificate Management.
Related Posts
- The DarkMatter Debate: Why Organizations Need to Actively Protect Trust Stores
- Mozilla CA Quandary Highlights the Importance of Trust Store Security
- Serial Entropy Issues Invalidate 22,000 TLS Certificates on Dutch Government PKI
- Google, Apple, GoDaddy Mis-issue Over 1 Million Faulty Certificates
