AWS for Industries
Supporting digital signature and secure message transmission with AWS KMS and AWS Secrets Manager for Brazilian Instant Payment System
As discussed in the previous blog, the new Brazilian Instant Payment System (PIX) aims to speed up payments messaging and the availability of final funds to the beneficiary. The PIX results in reduction of costs, increasing security and improving the customer experience. AWS provides the necessary certifications and compliance standards for financial institutions to comply with PIX requirements, such as encryption and digital signature of messages in XML format.
It is worth remembering that the defined security structure, between the mandatory and recommended requirements, is detailed in the previous blog.
We previously described how financial institutions could utilize AWS CloudHSM in order to provide digital signatures, mTLS (mutual TLS), and logging. In this follow up post, we focus on how financial institutions can use cryptography services like AWS Key Management Service (AWS KMS) and AWS Secrets Manager to comply with the security guidelines of the Brazilian Central Bank (BACEN) and connect to the PIX.
Benefits for financial institutions
There are some key benefits for Brazilian financial institutions when using AWS KMS to create an architecture for connecting to the PIX:
- Keep data encrypted at rest and in transit;
- Digitally sign messages and establish a TLS tunnel with mutual authentication;
- AWS KMS starts with a default value of 500 TPS (transactions per second) for cryptographic operations with asymmetric RSA keys. However, it is a soft limit and it is possible to increase the value via Service Quotas;
- Scalability, availability, and native integration with other AWS services;
- AWS KMS is an AWS managed service for secure storage and use of cryptographic keys, validated at FIPS 140-2 Level.
- Customers can realize a reduction in operational load and operating costs related to server management and security, because AWS KMS is a serverless architecture.
Main AWS services used in the proposed architecture
Application to sign XML messages and establish mTLS tunnel
Amazon API Gateway is a managed service that allows developers to easily create, publish, maintain, monitor, and protect APIs at any scale. API Gateway handles all tasks involved in receiving and processing up to hundreds of thousands of simultaneous API calls, including traffic management. You can authorize API calls and limit traffic to ensure that backend operations support peak traffic and backend systems are not called out unnecessarily.
With the applications running on AWS Lambda, financial institutions can run code without provisioning or managing servers. You pay only for the computing time consumed. Customers can run the code for almost any type of application or backend service, all without administration, with AWS Lambda. Just load the code and Lambda takes care of all the necessary items to run and scale the code with high availability. You can configure your code to be triggered automatically by other AWS services or call it directly using any mobile or web application.
The use of services with a serverless approach allows customers to focus on application development and not on the operational requirements of server management. Thus, the financial institution focuses on delivering value to the business.
AWS offers several tools to monitor and troubleshoot AWS Lambda applications, and respond to potential incidents, such as: Amazon CloudWatch, Amazon CloudWatch Logs, AWS CloudTrail, AWS Trusted Advisor, and AWS X-Ray. If you want to learn more about how to implement logging strategies on AWS, click here. You should collect monitoring data from all parts of your AWS solution to make it easier to debug a failure or investigate an incident.
Log registration (audit)
One of the requirements of BACEN is that the financial institution must store the record of the request and response for each transaction. Consistent recording of transactions is essential for auditing, in addition to solving and identifying problems.
The architecture demonstrated on this blog post is an event-driven architecture. We use Amazon Kinesis Data Firehose, a fully managed service for streaming data delivery in near-real time, as an event stream, and persist the records on Amazon S3.
Amazon Athena and AWS Glue Data Catalog are used to run interactive queries on log files placed on Amazon S3 with standard SQL and provide an index for location metrics, layout, and execution time of your data. You can use the information in the Data Catalog to create and monitor your ETL jobs. The information stored in the Data Catalog is retained as metadata tables, where each table specifies a single data store. Typically, you run a crawler to inventory the data, but there are other ways to add metadata tables to your Data Catalog.
Cryptography and digital signature
AWS Secrets Manager
The AWS Secrets Manager service allows a financial institution to easily rotate, manage, and retrieve secrets such as database credentials and API keys throughout their lifecycle. Users and applications retrieve secrets with a call to the AWS Secrets Manager API.
With AWS Secrets Manager, you can help protect secrets by encrypting them with keys that you manage with AWS KMS. A secret in AWS Secrets Manager consists of the protected secret data and the important information needed to manage the secret. We use AWS Secrets Manager to store the private key that will be used to establish the TLS tunnel with mutual authentication with BACEN.
AWS KMS
AWS KMS is a managed service that makes it easier for financial institutions to create and control customer master keys (CMKs), and the encryption keys used to encrypt their data. AWS KMS CMKs are protected by hardware security modules (HSMs) validated by the FIPS 140-2 cryptographic module validation program.
Figure 1 – AWS KMS architecture.
AWS KMS features
- AWS KMS allows you to perform digital signature operations using asymmetric key pairs to ensure data integrity.
- Uses hardware security modules (HSMs) validated or in the process of being validated by FIPS 140-2 at level 2 to generate and protect keys.
- Friendly API (symmetric and asymmetric keys) and integrated with the AWS Encryption SDK (symmetric keys only).
- Inability to extract private keys.
- Integrated with AWS CloudTrail to log all API requests, including key management actions and usage of your keys.
- Low-cost service. There are no upfront charges for using AWS KMS.
- AWS Managed Services, where AWS manages the maintenance aspects of the service and customers fully control the cryptographic aspects of the service.
Architecture
The architecture presented in this blog post can be part of a more complete event-driven solution that can detail the entire payment message transmission flow from the banking core. For example, the complete solution of the financial institution (paying or receiving) could contain other complementary architectures such as Authorization or Undo (based on the SAGA model) ensuring effectiveness in communication with on-premises environments (hybrid environment). The customer may need to use other services in completing the hybrid solution such as:
- Amazon EventBridge
- Amazon Simple Notification Service (Amazon SNS)
- Amazon Simple Queue Service (Amazon SQS)
- AWS Step Functions
- Amazon ElastiCache
- Amazon DynamoDB
In the following diagram of our architecture, the green box represents the communication Proxy with the Central Bank.
To establish communication, the Proxy utilizes AWS KMS, AWS Lambda, Amazon API Gateway, and AWS Secrets Manager.
The idea of the Proxy is to be a direct and mandatory path for every transaction, with the following objectives:
- Signature of XML messages.
- Establishment of the TLS tunnel with mutual authentication (mTLS).
- Sending the request log to the data stream.
Private APIs were used in this architecture, unlike in the AWS CloudHSM architecture where we use Elastic Load Balancing (ELB) to balance different messages. Amazon API Gateway distinguishes between the two types of messages.
It is also worth mentioning that we use AWS KMS to sign documents with the requirements established by PIX. It is necessary to generate a Certificate Signing Request (CSR) and obtain a valid digital certificate. To learn how to generate a CSR for asymmetric keys managed by AWS KMS, see here.
Optionally, the financial institution can view the transactions that this solution processes using Amazon QuickSight. Amazon QuickSight’s serverless architecture allows you to provide insights to anyone in your organization you need, and you can share interactive and sophisticated dashboards with your users, allowing them to do detailed searches, explore data to answer questions, and gain relevant insights.
Proxy
The following figure represents the architecture, and the step by step of the secure message transmission flow to BACEN and the respective response.
- Create the private key (for signature) in AWS KMS.
- Create the secret in AWS Secrets Manager with the content of the private key used for mTLS.
- Store the two certificates in the AWS Systems Manager Parameter Store: generated key certificate for signature, certificate generated for the mTLS.
- The financial institution service/application sends the request in XML format.
- Amazon API Gateway sends the XML message to the application running on AWS Lambda.
- The application (AWS Lambda) uses AWS KMS for digital signature of XML.
- The application (AWS Lambda) uses the private key stored in AWS Secrets Manager to establish the mTLS.
- The application transmits the signed XML to BACEN in an encrypted tunnel (mTLS).
- Application (AWS Lambda) receives the response from BACEN and, if necessary, validates the digital signature of the received XML.
- Application (AWS Lambda) records the request log sending directly to Amazon Kinesis Data Firehose.
- The reply message is sent to the Amazon API Gateway.
- The reply message is received by the service/application.
- Amazon Kinesis Data Firehose uses the AWS Glue Data Catalog to convert the logs to parquet format.
- Amazon Kinesis Data Firehose sends the logs to Amazon S3, already partitioned into “folders” (/year/month/day/hour/).
- Amazon Athena uses the AWS Glue Data Catalog as a central place to store and retrieve table metadata.
- AWS Glue crawlers automatically update new partitions in the metadata repository, every hour.
- You can immediately query the data directly on Amazon S3 using serverless analysis services, such as Amazon Athena (ad hoc with standard SQL) and Amazon QuickSight.
Costs and TPS
You can consult the AWS KMS usage price at this link.
To make AWS KMS responsive and performant for all users, AWS KMS applies two types of quotas. Each quota is calculated independently for each Region of each AWS account:
- Resource quotas: Limit the number of each type of AWS KMS resource.
- Request quotas: Limit the number of requests for AWS KMS API operations in a specified interval.
If necessary, it is possible to request the increase to meet the need for your use case.
You can consult the AWS Secrets Manager usage price at this link.
Conclusion
Using AWS services, financial institutions have the control and confidence necessary to run their business safely in the most flexible and secure cloud computing environment available.
BACEN (SFN) security requirements regulate the Brazilian banking system and to connect to the PIX. Thus, with AWS services, the financial institution can improve its ability to meet key security and compliance requirements, such as location, data protection, and confidentiality.
AWS allows financial institutions to automate security tasks so you can focus on scaling and innovating your business. In addition, financial institutions pay only for the services they use. The architecture presented not only includes the security part for digital signature and transmission (mTLS) of messages, but also includes the mandatory logging of requests.
Artifacts
To make it easier to understand and deploy our solution, we share the source code in the aws-samples/pix-proxy-samples repository on GitHub.
- You can clone, change, run it, but it is provided as an example only and should not be used partially or completely in the final integration of the financial institution with BACEN.
- All the information needed to deploy and test the example can be found directly in the README file of the repository.
For the development and testing of the solution, we created a simulator to represent the BACEN environment. In this simulator, we require client authentication (Proxy) to support the requirement of mTLS. In addition, we perform the digital signature validation of the requests received, and digitally sign the response to be sent to the Proxy.
- On average, Get Claims requests get a response time of 78 ms (depends on the amount of computational resources in the container and size of the response message), measured from the service/application. Flow:
- Service/application → Proxy (mTLS) → Simulator (sign response) (mTLS) → Proxy (valid signature of response) (stores request log) → Service/application.
- On average, Insert Claim requests obtain a response time of 122 ms (depends on the amount of computational resources in the container and size of request and response messages), measured from the service/application. Flow:
- Service/application → Proxy (sign the request) (mTLS) → Simulator (validate the signature of the request) (sign the response) (mTLS) → Proxy (valid signature of the reply) (store the request log) → Service/application.
Further reading
- AWS PIX 1 series: Supporting digital signature and secure message transmissions for Brazilian Instant Payment Systems with AWS CloudHSM (blog post).
- Use Asymmetric keys in AWS KMS for Certificate Signing Requests using the Java Cryptography Extension (GitHub repository).
- How financial institutions can approve AWS services for highly confidential data (blog post).
- Improving fraud prevention in financial institutions by building a liveness detection architecture (blog post).
- Digital signing with the new asymmetric keys feature of AWS KMS (blog post).
- How to verify AWS KMS asymmetric key signatures locally with OpenSSL (blog post).