Trusted Platform Module Overview
Learn about trusted platform module (TPM), use of TPM-based certificates and benefits.
A Trusted Platform Module (TPM) is a hardware component that ensures your device is running optimally. It serves as a secure storage mechanism for essential security artifacts such as cryptographic keys and digital certificates.
TPM-Based Certificates
Starting in Junos OS Release 24.2R1, you can use the TPM based certificate with SRX1600, SRX2300 and SRX4300 Series Firewalls.
The firewall uses the TPM-based certificate to ensure secure identification of the device. The firewall has burnt-in idev-id certificate built on TPM. The idev-id certificate provides the firewall’s JNPR serial number and model, proving that the firewall was manufactured in a Juniper facility. Hence, TPM certificate is a secure way for a Juniper device to prove its identity.
- Benefits of TPM-Based Certificates
- How Does a Conventional SSL/TLS Certificate Work?
- How Firewall Manages the TPM-Based Certificates Using PKI
- How AAMWD and SSL/TLS Use TPM-Based Certificates
Benefits of TPM-Based Certificates
-
Provides trust. Helps to establish advanced security in an insecure digital world.
-
Provides confidentiality. Data sent is encrypted and only visible to the server and client.
-
Provides integrity. Ensures that the data has not been modified during the transfer.
How Does a Conventional SSL/TLS Certificate Work?
Secure Sockets Layer (SSL) is a protocol that allows encryption. It helps to secure and authenticate communications between a client and a server. It can also secure email, VoIP, and other communications over unsecured networks. SSL is also called as Transport Layer Security (TLS).
In unsecured HTTP connections, hackers can easily intercept messages between client and server. SSL certificates use a public/private keypair system to initiate the HTTPS protocol. Hence, SSL certificates enable secure connections for users and clients to connect. SSL/TLS works through:
- Secure communication that begins with a TLS handshake. The two communicating parties open a secure connection and exchange the public key.
- During the TLS handshake, the two parties generate session keys. The session keys encrypt and decrypt all communications after the TLS handshake.
- Different session keys encrypt communications in each new session.
- TLS ensures that the user on the server side, or the website the user is interacting with, is who they claim to be.
- TLS also ensures that data has not been altered, since a message authentication code (MAC) is included with transmissions.
When a signed SSL certificate secures a website, it proves that the organization has verified and authenticated its identity with the trusted third party. When the browser trusts the CA, the browser now trusts that organization’s identity too.
The easiest way to check if the website has an SSL installed is to see if the website URL starts with “HTTPS:”. If the website has an SSL certificate installed on the server, click the padlock icon in the address bar to view the certificate information.
How Firewall Manages the TPM-Based Certificates Using PKI
When you use applications such as the advanced anti-malware detection (AAMWD) using Juniper ATP Cloud, you can use the TPM-based certificate for attestation, allowing the applications to verify the legitimacy of your device. The firewall manages the TPM-based certificates using the PKID process. Note the following when using PKID process for TPM-based certificates:
-
The firewall loads the TPM-based certificate using the PKID process during the device start and restart operations.
-
The device loads the certificate and the private key handle against the TPM based certificate ID, referred as
idev-id
certificate ID, from your device's local certificate list. To view the TPM-based certificate ID, referred asidev-id
, use theshow security pki node-local local-certificate certificate-id idev-id
command. -
You should not use the command
request security pki node-local local-certificate verify certificate-id idev-id
to verify theidev-id
certificate ID. The verification doesn't go through as the CA certificate for theidev-id
certificate ID is not available on your firewall. You'll notice an error messagelocal certificate verification can't performed for IDev-ID certificate as the CA cert for the same is not available
when you try to verify using the command.
How AAMWD and SSL/TLS Use TPM-Based Certificates
Applications such as the AAMW detection (AAMWD) using Juniper ATP Cloud on SRX Series Firewall must use the TPM burnt-in certificate for all its device identification and authentication instead of conventional certificates. This helps to establish a secure client authenticated SSL connection with the cloud server using the new TPM certificate. This applies to both control and data plane (SSL-I)/TLS connections established by AAMWD. The cloud server confirms the authenticity of TPM private key using TPM public key that is shared in SSL handshake. The device identification information is part of the shared TPM certificate.
When you configure SSL-Initiation (SSL-I) profile, there's a requirement on PKID side to load the TPM certificate and private key handle on start/restart against a certain certificate ID. You can use this certificate to configure the SSL-I profile. This certificate can be used by AAMWD for TLS connections. SSL-I need changes on data plane side to use TPM chip for sign/verify purpose for AAMWD TLS connections. SSL-I provide the SSL client functionality to ATP Cloud with client authentication. SSL-I mode needs to be supported with TPM certificate/private key. Earlier, SSL-I use the file system local certificate and private key.
Starting in Junos OS Release 24.2R1, you can use SSL-I in two modes:
-
SSL-I with TPM certificate/keys
-
SSL-I with file-system certificate/key
You can configure the tpm
option using the set services ssl
initiation profile profile-name crypto-hardware-offload
command.