Zero Trust – The Importance of Cryptography, Key Management, and Confidential Computing

Zero trust architecture promises to solve many of today’s challenges in information security. Here, we look at what “zero trust” means, the role of cryptography in implementing a zero trust architecture, and the importance of key management. We also detail how confidential computing enables zero trust to be taken to the next level.

The Problem with Classical Information Security

Information security is fundamentally about protecting data. The classical walled garden approach to information security keeps data within a closed network, protected from the outside world by firewalls; users either have local access to the network or come in through a VPN from an approved corporate endpoint. In this architecture, access to the network enables access to the data.

However, with the growth of remote access (particularly during the COVID-19 pandemic), the proliferation of SaaS applications, the migration towards cloud-based infrastructure, and the adoption of bring your own device (BYOD), there is no longer a clearly-defined network boundary to defend. When combined with increasingly sophisticated cyberattacks, it is now virtually impossible to protect the network, and hence the data with perimeter based security. A completely new approach is needed.

Zero Trust Architecture to the Rescue

“Zero trust architecture” has emerged as the solution to this problem. It assumes that users and the resources they want to access can be anywhere, and that the intervening network is untrusted. Data is protected by (i) authenticating and authorizing access to the data, and (ii) encrypting the data, both at rest and in transit. According to the US National Institute of Standards and Technology (NIST) Special Publication 800-207, entitled “Zero Trust Architecture” [ref 1]:

Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources … Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.

There are a few competing approaches to implementing a zero trust architecture, such as network micro-segmentation, software-defined perimeter, and identity-aware proxy. Each has its particular merits, which we will not explore here, but they all essentially employ the same principles outlined above. Google is widely credited with popularizing the concept of zero trust with their BeyondCorp architecture [ref 2].

Note that using a zero trust architecture does not mean that all other cybersecurity mechanisms are redundant. You still need to defend against network intrusions and malware, which could compromise data-in-use, cause denial-of-service, or utilize your resources for nefarious purposes (such as cryptojacking). One notable weakness of zero trust architecture is that it cannot protect against a stolen identity, which means that strong, multi-factor authentication should applied as part of a defense in depth strategy.

The Role of Cryptography

Cryptography lies at the core of modern cybersecurity and is critical to the implementation of a zero trust architecture. Cryptographic algorithms enable data to be encrypted (for confidentiality) and signed (for integrity and authenticity). In particular, public key cryptography enables the identification and authentication of users and endpoints using digital certificates, as well as the establishment of secure end-to-end tunnels over untrusted networks using Transport Layer Security (TLS).

Tokenization is another useful cryptographic technique in the zero trust arsenal. Tokenization typically uses format-preserving encryption to replace the original data with an encrypted version of the data in the same format (i.e. same length, character set, and format). This enables sensitive fields within a database to be selectively encrypted without affecting the data base schema. Tokenization is performed by a special tool, which also controls who has access to the encryption key and can therefore decrypt the tokenized data fields; unauthorized users (or applications) will only see the tokenized data, which looks like real data and can be stored and processed in the same way, but is actually just a random substitute for the real data.

Here are some specific cryptographic security recommendations from the UK National Cyber Security Centre (NCSC) “Zero Trust Architecture Design Principles” [ref 3]:

  • Identity stored on a secure hardware co-processor, like a Trusted Platform Module (TPM), will give you high confidence in the device’s identity
  • Systems that implement attestation to gain confidence in initial device state, may include subsequent cryptographic checks of launched applications and services to extend the breadth of health measurements regarded as strong signals.
  • Each request to a service should be authorized against a policy. Use products and protocols that support this continuous authentication and authorization process, while protecting your data in transit with encryption.
  • Attacks targeted at foundation network services, such as DNS, can often only be mitigated at higher layers in the stack, for example ensure that services your users are accessing are protected with authenticated and encrypted protocols, such as TLS.
  • Whenever possible, use standards-based technologies. This allows interoperability between devices and services. A good example is authentication, where common standards such as OpenID Connect or SAML allow you to use a single directory service to authenticate to many services.
  • Requests between services also need to be authenticated. This is normally achieved using API tokens, frameworks such as OAuth or Public Key Infrastructure (PKI). Use mutual authentication wherever possible.

The Importance of Key Management

We have seen that zero trust architecture is all about identity, access control, and encryption, which each rely heavily on cryptography. Cryptography, in turn, depends on keys - data encryption requires an encryption key, digital certificates require a private/public key pair. The protection afforded by cryptography is only as good as the key, and the compromise of a key completely invalidates that protection. Thus, for good security, keys must be cryptographically strong, of a length that complies with corporate policy, kept secure at all times, and properly managed over their lifecycle. For instance, you need to control who (users) and what (applications) have access to specific keys, what they’re allowed to do with them, when the keys expire (or are rotated), and ensure that keys are deleted when no longer required. Furthermore, every action on the keys should be logged for audit and compliance purposes.

In today’s enterprise, cryptography is already used extensively to protect data at rest (largely for privacy reasons), as well as for protecting data in motion and for PKI and digital identity. Zero trust architecture places an even greater dependence on these things. However, this creates a challenge in terms of managing the large number of keys required by hundreds of different applications and thousands of users, both on-premise in the cloud. The only way to efficiently and effectively do this is by means of an enterprise key management system, providing centralized management and control that is consistent with corporate governance requirements and external standards and regulations.

Taking Zero Trust to the Next Level with Confidential Computing

One of the biggest security threats that zero trust architecture doesn’t specifically address is the vulnerability of data in use, i.e. the fact that applications and their data are exposed in system memory at runtime and thus open to various attacks.

If we extend the concept behind zero trust to say that, not only do we not trust the network, but we don’t trust the compute infrastructure, operating system, or applications running on servers either (particularly in the cloud), then we need an effective defense for data in use.

Defenses such as anti-malware and intrusion protection systems are not 100% effective and are often completely ineffective against zero day attacks that haven’t been seen before or are customized for a specific attack. There will always be the risk of zero-day attacks, CSP insider threats and malicious system administrators. Fortunately, the emergence of “confidential computing” using trusted execution environment (TEE) technology baked into CPUs at the hardware level, such as Intel® Software Guard Extensions (SGX), offers a solution [ref 4].

Confidential computing is a game-changing technology that enables applications to run inside a “secure enclave”, inaccessible even to the operating system and virtual machine manager. An attestation process is used to validate the CPU and the application, which is digitally signed for integrity and authenticity, while both the application and its data are encrypted even in system memory at runtime. The attack surface, or trusted computing base, is reduced to the CPU and the application that are authenticated and running inside the secure enclave – nothing else inside (or outside) the system needs to be trusted. Thus, even if an attacker has root privileges or physical access to probe the memory bus, the application and its data remain secure.

Fortanix Solutions for Zero Trust Architecture

Fortanix has pioneered confidential computing solutions for over 4 years and today has solutions deployed within mission-critical production environments at many Fortune Global 500 companies. The following solutions from Fortanix help provide data security for zero trust architectures:

Fortanix Self-Defending Key Management Service provides a modern, scalable, and cloud-friendly solution for enterprise key management, HSM, secrets management and tokenization. Built on Fortanix Runtime Encryption® confidential computing technology, it supports standard cryptographic APIs such as PKCS#11, JCE and CAPI/CNG alongside a powerful and comprehensive REST API for application developers and DevOps teams, enabling seamless integration with both 3rd-party applications and in-house applications.

Advanced features to assist in building a zero trust architecture include:

  • User-defined accounts and groups to segment access to keys by users and applications
  • User-defined cryptographic policies for compliance with corporate governance requirements
  • User-defined quorum policies to protect against malicious insiders or identity thieves
  • User-defined scripts (“secure plugins”) to implement bespoke business logic and controls
  • Comprehensive audit logging and integration with SIEM tools

Self-Defending KMS also complies with zero trust architectural best practices itself, through:

  • Authentication of users with 2FA and integration with enterprise SSO tools
  • Authorization of users by means of role-based access control
  • Authentication of applications by API key, certificate, trusted CA, JWT, and IP whitelisting
  • Full protection of keys using encryption at rest, in motion, and in use

Enclave Development Platform (EDP) is an open-source toolset for developing your own confidential computing applications running inside secure enclaves using the Rust programming language.

Enclave Manager enables you to convert your existing containerized applications to run inside a secure enclave and to orchestrate and manage confidential computing applications across your on-premise or private/public cloud infrastructure.

References

  1. https://csrc.nist.gov/publications/detail/sp/800-207/final
  2. https://cloud.google.com/beyondcorp
  3. https://www.ncsc.gov.uk/blog-post/zero-trust-architecture-design-principles
  4. https://confidentialcomputing.io/white-papers/

See also:

Using confidential computing to protect faas

Share this post:

Get our blog updates in your inbox: