Skip to main content
banner image
venafi logo

What Are Trust Anchors and How Can They Protect You?

What Are Trust Anchors and How Can They Protect You?

Trust anchors, DarkMatter, Mozilla, trust store, certificate authority
April 3, 2019 | Diederik Klijn

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?

  1. How can we be confident that a new device requesting a certificate (and the keypair 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?
  2. 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?
  3. Or maybe we need to protect patented hardware so that cheap clones are not able to run expensive, proprietary software.
  4. 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.

Related posts

Like this blog? We think you will love this.
person working on a laptop with halloween decorations around them
Featured Blog

4 Spooky Mistakes that Can Haunt Your PKI

Here’s what can go horribly wrong. Read on if you dare.

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection
Industry Research

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

Diederik Klijn
Diederik Klijn

Diederik is a Sales Manager for Northern Europe at Venafi. He is currently leveraging his two decades of experience in IT Security to solve cybersecurity challenges revolving around machine identities in northern Europe.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat