How exactly to verify AWS KMS signatures within decoupled architectures at scale

      AWS Important Management Support (AWS KMS)           makes it simple to generate and manage cryptographic keys in your programs. The service helps both symmetric and asymmetric           customer expert keys (CMKs)          . The           asymmetric CMKs           offer you digital signature ability, which data consumers may use to verify that information is from the trusted producer and will be unaltered in transit.

AWS KMS provides convenient API strategies over asymmetric CMKs which you can use to both sign and verify signatures. However, if you want to verify a signature in high-throughput or decoupled architectures, utilizing the AWS KMS API is probably not practical. This blog article describes a delegated authorization make use of case, to illustrate how to overcome this issue at scale. In our use situation, AWS KMS indicators the data, however the verification is conducted in independent, distributed conditions.


If you’re thinking about signing JSON Internet Tokens (JWTs) with AWS KMS, and later on validating those signatures in large-scale distributed applications, read on for a good example use situation and working code good examples.

About signature verification

Digital signatures

In public-key cryptography, creating a electronic signature requires the personal type in a public/personal key set, whereas verifying the signature requires just the public key. Through the use of regular signing, hashing algorithms, and important parameters, receivers can verify signatures in virtually any atmosphere that has usage of the public crucial.

Oftentimes, you verify signatures more regularly than you issue them-consider how an API token may be signed once every hour but is verified a large number of times every 2nd. Signing entities may also end up being disconnected at verification time-consider how verifying SSL/TLS certificates doesn’t need a link with the certificate issuer.

You may use these asymmetries in your favor when you design powerful and distributed delegated authorization techniques.

When to verify signatures beyond AWS KMS

Verifying signatures without phoning AWS KMS could be necessary in the next scenarios:

Decoupled verification&lt and signing;/h2>

Physique 1 illustrates how exactly to decouple the Signer, predicated on AWS KMS, in one or even more independent Verifiers. This technique involves the next steps:

  1. Throughout system set up, the Signer will be provisioned having an asymmetric key set. Signers such as for example AWS KMS support inner hardware protection module (HSM)-backed, high-entropy asymmetric key generation and administration.
  2. The Verifiers are configured to trust the Signer via an offline import of the Signer’s public key.
  3. During runtime, AWS KMS will be requested to hash and develop a digital signature more than some original information. AWS KMS hashes the offered information and uses the personal type in the asymmetric essential set to compute the signature on the hash. The initial data, alongside its signature, is sent to litigant.
  4. Your client forwards the info and signature to 1 or more Verifiers, and requests usage of their protected resources.
  5. The Verifiers verify the signature that’s linked to the original data. The Verifiers utilize the Signer’s public type in this process. If the verification succeeds, and therefore the original data that has been conveyed will be unaltered and authentic, the Verifiers grant your client usage of their protected sources.

Determine 1: Digital signature signing and verification inside decoupled environments

Figure 1: Digital signature signing and verification inside decoupled conditions

Example use situation

In the event that you curently have a use situation and need to get right to the code, it is possible to skip to the Deploy the solution area. If you’d prefer to understand an example use case comprehensive, continue reading.

We’ll look at what sort of healthcare authority inside the COVID-19 Publicity Notification System (ENS) reference architecture may use AWS KMS fronted by AWS Lambda compute to certify (sign) a patient’s analysis that’s embedded within JWT statements. This certification makes it possible for independent health care authorities to verify a patient’s diagnosis while furthermore preserving the personal privacy of the individual.

Our instance makes use of Elliptic Curve Digital Signature Algorithm (ECDSA) signatures, even though techniques presented could be equally put on other public-important cryptography algorithms, such as for example RSA. We offer example program code in the Golang and Python programming languages, and also example OpenSSL instructions. A earlier blog post describes AWS KMS RSA signature verification making use of OpenSSL commands. Start to see the Appendix by the end of the post for home elevators our ECDSA key construction in AWS KMS.

It is possible to generalize out of this use case to your personal architecture utilizing the included code illustrations.

Situation: Exposure notifications inside COVID-19 digital get in touch with tracing

Within COVID-19 electronic contact tracing, the Direct exposure Notifications program validates that medical diagnosis test results are from the legitimate, trusted testing service, while protecting the identification of the individual. To facilitate privacy-preserving contact tracing, the machine creates an anonymizing chain of have confidence in with electronic signatures.

The machine allows for healthcare authorities to send notifications of potential exposure through cellular devices to users whose phone was close to the phone of a user with confirmed positive COVID-19 diagnosis. To safeguard identity and private information, neither the originating consumer nor the receivers understand each other’s identification or location of publicity.

Number 2 illustrates the architecture. An Publicity Verification Server (EVS) offers a group of APIs that permit the mobile user (individual) and the general public health authority employee to supply cryptographic evidence a positive analysis was issued by way of a verified laboratory.

An Direct exposure Notification Server (ENS) receives trusted, anonymized exposure info from registered mobile apps, and subsequently sends out a possible direct exposure notification to all cellular devices in the configured domain. Each mobile software utilizes the aggregated, anonymous details (Temporary Publicity Keys, or TEKs) to calculate potential publicity.

In this illustration, the EVS services is working in the AWS Cloud and uses AWS Lambda with usage of AWS KMS for signing. The ENS is operating elsewhere, administered by a alternative party.

The Direct exposure Notification Program architecture has properties that control direct usage of the AWS KMS API:

  • The EVS and ENS servers haven’t any connectivity, and so are operated by various entities
  • The ENS server validates a higher volume of signatures, millions per day&lt potentially;/li>

Figure 2: COVID-19 Publicity Notification System with AWS-based EVS

Figure 2: COVID-19 Direct exposure Notification Program with AWS-based EVS

Let’s stroll through each stage and show ways to use an offline electronic signature verification to move information by way of a chain of confidence, without revealing identity, whilst helping to make sure that any tampering of medical diagnosis results could be detected.

  1. At program set up, an administrator for the EVS that’s of a laboratory service generates an ECDSA signing crucial pair through the use of AWS KMS. The administrator, with respect to the laboratory facility, registers with the ENS by giving information regarding the laboratory and the general public key of the ECDSA key pair. These details handoff also contains metadata about the essential and signing parameters, such as the important identifier, the elliptic curve found in creation of the main element, and the hashing algorithm that has been utilized. The ENS establishes have faith in by way of a contractual, offline procedure. (“We know it is a valid service.”)
  2. The user participating in Publicity Notifications is identified as having COVID-19. THE GENERAL PUBLIC Health Authority (PHA) problems a short-resided, human-readable, one-time code for an individual to enter their mobile application, released by the EVS. The one-time program code is short and possible for a human to utilize, but is therefore restricted in the safety protections it offers.
  3. The application form exchanges the one-time code for a temporary API token, which improves the security of subsequent communications. The app walks an individual through health-related queries without prompting for just about any identifying information.
  4. TEKs are usually generated on the telephone and so are transmitted to close by phones through the use of Bluetooth Low Power signals. When a cell phone detects the TEK of another telephone, this means that both phones have already been physically nearby for an adequate time and energy to pose an direct exposure risk. The phones constantly transmit and collect TEKs. At a predefined interval, the telephone gathers its gathered TEKs over the time period, applies a hash functionality, and transmits the resulting hash to the EVS for signing. The short-term API token secures this API contact.
  5. The Lambda functionality in EVS phone calls AWS KMS to indication a JWT utilizing the ECDSA key that has been created in step one 1. The JWT consists of custom claims a person of a mobile gadget was identified as having COVID-19 on a particular day, and the hash of the TEKs, but includes no identifying information regarding the person or these devices. The EVS returns the signed JWT to the cellular application.
  6. The signed JWT and the TEKs are delivered to the ENS for widespread distribution of the TEKs. The ENS validates the identification of the EVS by extracting the main element identifier embedded in the obtained JWT and coordinating the main element identifier against its formerly configured worth from step one 1. The ENS after that cryptographically verifies the electronic signature. Following this process is total, the ENS has evidence that a trusted laboratory provided the results, but doesn’t possess information about the specific patient.
  7. The TEKs are distributed to the prospective geography. The cellular phone program checks the downloaded TEKs against its set of generated TEKs, and alerts an individual of potential exposure in case a match is available.

Architecture advantages

The ENS server must know that JWTs which are submitted for distribution represent legitimate diagnoses. At a nationwide scale, calling an exterior API for each and every digital signature check will be prohibitively costly and complicated. By looking at signatures transmitted with the information at the idea of receipt without external dependencies, the system could be faster and much more reliable.

Even though public health authority representative must know the patient’s identity, the distribution server will not. Through the use of digital signatures, you develop a chain of anonymized trust-the notification server trusts the verification server, and the JWT’s signature from the verification server applies that faith and detects alterations of the info.

Signed JWTs will be the key architectural component which makes this system possible. Now that you’ve observed why you might like to make use of signed JWTs, let’s appearance at how to use them.

Deploy the answer

In this area, we provide code good examples that implement actions in the example situation. We’ve held the signing program code domain-agnostic; you can adjust it to your personal use situation.

Indication a JWT

In step 5 in the preceding section, the ENV server signals a JWT, which indicates a recognized, trusted lab has provided results.

The JWT is signed based on the ES256 standard (ECDSA utilizing the P-256 curve and the SHA-256 hash) as needed by the EVS specification. The EVS program performs the following methods:

  1. Creates the JWT header that bears signing metadata, like the signature and hashing algorithm (for instance, Sera256) and the main element identifier used.
  2. Creates the JWT payload which has promises that assert the patient’s COVID-19 analysis and the hash of TEKs.
  3. Serializes the JWT header and payload JSON items in to strings and encodes them to bottom64url format. The machine then together concatenates both strings, separated by way of a period (“.”) character to create the string to end up being signed.
  4. Invokes the AWS KMS indication() API, inputting the ECDSA CMK ID, the string to become signed, and the signing algorithm to utilize.
  5. Encodes the binary signature bytes which were returned from AWS KMS into foundation64url structure.
  6. Appends the bottom64url signature string to the initial two elements of the JWT, separated by an interval character to make the ultimate JWT.
  7. Returns the JWT to the individual’s mobile app back again.

It is possible to implement the preceding ways in virtually any programming language utilizing the AWS KMS SDK or the AWS KMS HTTP API. The next code shows a good example execution in Golang that utilizes the AWS SDK for Move V2.

Take note: You’ll have to “&lt switch the values tagged;em><your…>” in every of the program code samples below.

package main

import (




func main()
// Load the Shared AWS Construction (~/.aws/config)
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil

     // Create an AWS KMS assistance client

customer := kms.NewFromConfig(cfg)

// According to the JWT specification (https://equipment.ietf.org/html/rfc7519),
// the JWT header, payload, and signature are bottom64url encoded strings
// concatenated by way of a period (‘.’) personality. The JWT signing string
// may be the JWT payload and header strings joined by way of a period character.
// Illustration signingString := “eyJhbGciOiJFUzI1NiIsImtpZCI6ImFsaWFzL0VOVlNfVlRfU0lHTklOR19LRVkiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJhd3MtZXhwb3N1cmUtbm90aWZpY2F0aW9ucy12ZXJpZmljYXRpb24tc2VydmVyIiwiZXhwIjoxNTk5NTg5NTM0LCJqdGkiOiJxMHg1N0lrRkMvSU9hdzAvNkpYVWhvaHFnV3RqZFVSaUNWMGpuVEpvR1BxTkNsbHdBWWhtTVJLUk1YOXUwb1I2bEtyTXNVSkdGZFJ6aCtncEJiakpCTWR4dVJBN3llYzEyWmE1SzJUMEFWWjZhMVdjNklYQ1ZlNGR6aHkyckJFbiIsImlhdCI6MTU5OTU4OTIzNCwiaXNzIjoiYXdzLWV4cG9zdXJlLW5vdGlmaWNhdGlvbnMtdmVyaWZpY2F0aW9uLXNlcnZlciIsInN1YiI6Im5lZ2F0aXZlLiJ9”
signingString := “”

// Populate signing parameters for the AWS KMS Sign() method
// https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/kms#SignInput
signingAlgorithm := types.SigningAlgorithmSpecEcdsaSha256
kid := “”
signInput := kms.SignInput
KeyId: &kid,
Message: []byte(signingString),
SigningAlgorithm: signingAlgorithm,

fmt.Printf(“Sign Input: %#vn”, signInput)

// Invoke the AWS KMS Sign() API
// https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/kms#Client.Sign
signOutput, err := client.Sign(context.TODO(), &signInput)
if err != nil

fmt.Printf(“Sign Output Signature: %vn”, signOutput.Signature)

// Convert signature bytes to base-64 URL encoding (without padding)
sigB64 := base64.RawURLEncoding.EncodeToString(signOutput.Signature)

// Append signature to first two elements of JWT to create signed JWT
signedJwt := strings.Join([]stringsigningString, sigB64, “.”)
fmt.Printf(“Signed JWT: %sn”, signedJwt)

Verify signatures


Because AWS KMS produces standardized, interoperable ECDSA signatures, you should use any standard implementation of ECDSA for verifying the signature. The Exposure performs this task Notification Server in the example, but you may use this code anywhere you intend to verify the signature that has been produced in the prior section.

All three of the next examples achieve exactly the same end result-they verify the signature. We’ve provided examples that use Golang, Python, and OpenSSL to show the flexibility in this process.

Signature verification in Golang

The Golang code shown in this section uses its built-in crypto package to verify the signature. The code performs the next :

  • Splits the input JWT string into individual parts (header, payload, and signature) separated by way of a period (“.”) character
  • Computes a SHA-256 hash of the signed string, that’s, the first two elements of the JWT string: the header and payload
  • Decodes the PEM-formatted ECDSA public key that has been extracted from AWS KMS within the EVS-to-ENS trust establishment
  • Converts the signature string from base64url characters to binary
  • Unmarshals the ASN.1 encoded signature and extracts the S and R integer values of the signature
  • Calls the ecdsa.Verify() method with the general public key, hash value, R, and S values of the signature arguments, and receives the verification outcome
package main

import (

func main()

Signature verification in Python

The Python code shown in this section uses the python-ecdsa module to verify the signature. The code performs the next steps:

    • Splits the input JWT string into individual parts (header, payload, and signature) separated by way of a period (“ . ”) character
    • Converts the signature string from base64url characters to binary
    • Verifies the signature with the general public key, signed string, and hash algorithm arguments, and receives the verification outcome
     import base64
from hashlib import sha256

import ecdsa
from ecdsa.util import sigdecode_der

Input your JWT string for signature verification.
The sample can be utilized by you JWT string and the next sample public key to perform this code. The signature in the sample JWT string below was produced utilizing the private key paired with the next sample public key.
#jwtStr = "eyJhbGciOiJFUzI1NiIsImtpZCI6ImFsaWFzL0VOVlNfVlRfU0lHTklOR19LRVkiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJhd3MtZXhwb3N1cmUtbm90aWZpY2F0aW9ucy12ZXJpZmljYXRpb24tc2VydmVyIiwiZXhwIjoxNTk5NTg5NTM0LCJqdGkiOiJxMHg1N0lrRkMvSU9hdzAvNkpYVWhvaHFnV3RqZFVSaUNWMGpuVEpvR1BxTkNsbHdBWWhtTVJLUk1YOXUwb1I2bEtyTXNVSkdGZFJ6aCtncEJiakpCTWR4dVJBN3llYzEyWmE1SzJUMEFWWjZhMVdjNklYQ1ZlNGR6aHkyckJFbiIsImlhdCI6MTU5OTU4OTIzNCwiaXNzIjoiYXdzLWV4cG9zdXJlLW5vdGlmaWNhdGlvbnMtdmVyaWZpY2F0aW9uLXNlcnZlciIsInN1YiI6Im5lZ2F0aXZlLiJ9.MEYCIQCiLqsE2bxKdDi3NvX0mXqcHbvvDtI9zcCwPUHQiQutoQIhAJDhhCdRSlk_QYU_7_9X11yEcPzNHWF4qq2wRG66w7Lh"
jwtStr = "                                                            "
jwtParts = jwtStr.split(".")

Compute a SHA-256 hash of the payload and header elements of the JWT string

signedStr = “.”.join(jwtParts[0:2]).encode(encoding=”ASCII”)
signature = base64.urlsafe_b64decode(jwtParts[2])


Decode the ECDSA public key copied from AWS KMS
Sample public key —
pubPemKey = (“—–BEGIN PUBLIC KEY—–n”

verifyKey = ecdsa.VerifyingKey.from_pem(pubPemKey)
if verifyKey.verify(signature, signedStr, sha256, sigdecode=sigdecode_der):
print (“Signature verification successful”)

print (“Signature verification failed”)

Signature verification with OpenSSL

You should use the openssl command line utility as shown following to verify the signature.

     openssl dgst -sha256 -verify pubkey.pem -signature sig.der msg.txt

In this command, you instruct openssl to compute a SHA-256 digest of an input message stored in msg.txt . Continuing with this JWT example, this file will support the first two elements of the JWT string-the header and payload separated by way of a period (“ . ”) character. This is actually the original message that has been hashed, and the resultant hash value will be verified contrary to the provided signature by OpenSSL. An example msg.txt is shown following.


You specify the file name which has the ECDSA public key- pubkey.pem . This is actually the ECDSA public type in PEM format that has been extracted from AWS KMS.

     vi pubkey.pem

---BEGIN PUBLIC KEY---                                                            ---END PUBLIC KEY---

An example pubkey.pem is shown following.

     -----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

The sig.der argument provides the signature bytes in DER format. It is possible to convert the base-64 encoded signature bytes in the JWT string in to the DER format with the next command.

     echo -n                                                         | base64 -D > sig.der

Sample signature bytes in base-64 are shown following.


The openssl command shall produce the next output if all of the parameters have already been provided properly.

     Verified OK

When to utilize AWS KMS for signature verification

Although this post shows how exactly to verify signatures without calling AWS KMS in a distributed use case, many scenarios reap the benefits of signature verification using AWS KMS. Such benefits are the following:

    • Achieve strong non-repudiation of the initial signed message
    • Immediately invalidate keys
    • Rotate key pairs to help keep signature verification synchronized with updated keys

For more help with using public keys beyond AWS KMS, see  Special considerations for downloading public keys .


Digital signatures allow one to perform fast and inexpensive checks on the authenticity of information and never have to get in touch with an external source.

AWS KMS is powerful and convenient, and made to solve a specific group of use cases perfectly. Sometimes, however, you may be designing a operational system that must share trust among different parties, or you may want to verify a signature with a public key that has been generated beyond KMS, or have performance requirements that produce calls to AWS KMS prohibitive. For these full cases, the techniques may be used by you in this article to create trusted systems predicated on digital signatures.

Appendix: ECDSA key configuration in AWS KMS

AWS KMS supports two popular digital signing mechanisms-ECDSA and RSA. We use ECDSA in this article as required in the EVS specification.

An ECDSA key is known as an asymmetric customer master key (CMK) in AWS KMS and will be created as described in Creating keys in the AWS KMS documentation. Figure 3 shows the cryptographic configuration for an ECDSA key created in AWS KMS.

Figure 3: Cryptographic configuration of an ECDSA key pair in AWS KMS

Figure 3: Cryptographic configuration of an ECDSA key pair in AWS KMS

The Key Type field in this configuration indicates that can be an asymmetric key. The Origin field indicates that key was generated within AWS KMS, instead of being imported.

The Key Spec field value of ECC_NIST_P256 indicates that key may be used to produce  NIST FIPS 186-4 (section 6.4)-compliant ECDSA signatures, where in fact the key was generated utilizing the curve labeled  secp256r1 .

The Key Usage field indicates that key may be used for signing and verification only. The Signing algorithms field indicates that the SHA-256 hashing algorithm can be used for computing the hash of the input message that’s signed or verified.

Other ECDSA key specifications could be chosen predicated on your security requirements and on guidance from the AWS KMS documentation .

When you have feedback concerning this post, submit comments in the Comments section below. When you have questions concerning this post, take up a new thread on the AWS KMS forum .

Want more AWS Security how-to content, news, and show announcements? Follow us on Twitter .

%d bloggers like this: