How to Secure Third‑Party API Calls with TLS, HMAC Signatures & RSA Encryption

Introduction

Modern enterprise systems frequently exchange data with third‑party services via APIs. When the payload includes personal data, payment details, or order information, communication security becomes a non‑optional, mission‑critical requirement.

Design Principles

Security First : Adopt mature, industry‑standard algorithms and protocols.

Separation of Duties : Manage our keys and the partner’s keys independently to avoid single points of failure.

Maintainability : Provide an SDK and clear documentation to reduce integration complexity.

Scalability : Support future interfaces and additional partners.

Controlled Performance : Keep cryptographic overhead within a few milliseconds.

Core Technical Solution

The solution implements a "three‑firewall" layered defense:

Mutual TLS + Request Signature + Data Encryption

Channel Security – Mutual TLS

Principle : Both client and server present certificates, preventing man‑in‑the‑middle attacks.

Implementation :

Issue certificates for our system and each partner using a trusted root CA.

Allow only clients presenting a valid certificate to access the API.

Enable mutual TLS verification in the edge proxy (e.g., Nginx or Envoy).

ssl_verify_client on;</code>
<code>ssl_client_certificate /etc/nginx/ssl/ca.crt;

Effect : Guarantees encrypted transport and authenticates the requestor’s identity.

Request Integrity – HMAC Signature

Principle : Compute a signature over critical request fields (method, path, timestamp, nonce, body) to create a tamper‑evident fingerprint.

Signing Flow (Client) :

Concatenate method + path + timestamp + nonce + body.

Calculate signature = HMAC‑SHA256(secretKey, payload).

Attach headers:

AppId: xxx</code>
<code>Timestamp: 1690000000</code>
<code>Nonce: e5f9f23c</code>
<code>Signature: 2f9afac7...

Verification Flow (Server) :

Lookup the Secret Key using the received AppId.

Re‑compute the signature with the same algorithm.

Validate that the timestamp is within an acceptable window (e.g., 5 minutes).

Compare the signatures; reject the request if they differ.

Effect : Ensures request integrity, prevents replay attacks, and authenticates the caller.

Data Confidentiality – RSA Encryption

Principle : Encrypt highly sensitive fields (e.g., ID numbers, bank cards) with the partner’s public RSA key.

Implementation Flow :

Generate an RSA key pair; keep the private key secret and share the public key with partners.

The partner encrypts sensitive fields using the public key.

Our service decrypts the payload with the private key.

Effect : Even if the TLS channel is compromised, encrypted fields remain unreadable, achieving end‑to‑end confidentiality.

Key & Certificate Management

Hierarchical Management :

Root certificates are stored offline and never expire.

API secrets reside in a secure configuration center (Vault/KMS) and rotate every six months.

RSA private keys are kept in a server‑side secure module and rotate annually.

Automatic Rotation : Keys are centrally managed and rotated automatically; the SDK detects version changes and switches seamlessly.

Monitoring & Alerting

Log Content : Record AppId, signature verification result, source IP, and request latency; forward logs to ELK/Loki.

Alert Rules : Trigger alerts on repeated signature failures or anomalous IP activity; notifications sent via SMS, email, or enterprise chat.

Performance & Stability Assessment

Typical latencies observed in production:

HMAC‑SHA256 signature: ~0.1 ms (cached secret).

RSA‑2048 encryption/decryption: ~0.8 ms (optimizable with AES‑RSA hybrid).

Mutual TLS handshake: ~20 ms (mitigated by long‑lived connections).

Optimization Suggestions :

Make signature verification and decryption idempotent.

Cache recent nonces in Redis to block replay attacks.

Apply rate‑limiting at the API gateway.

Compliance & Auditing

The solution aligns with GB/T 22239‑2019 (China’s Classified Protection 2.0), OWASP API Top 10, and PCI‑DSS requirements. Auditing includes semi‑annual security scans, logging key rotations, and retaining critical logs for at least 180 days.

SDK & Integration Specification

The provided SDK automates signature generation, timestamp/nonce handling, and error handling. Example (Java):

String payload = JSON.toJSONString(data);</code>
<code>String nonce = UUID.randomUUID().toString();</code>
<code>String timestamp = String.valueOf(System.currentTimeMillis());</code>
<code>String signature = HmacUtils.hmacSha256Hex(secretKey, payload + nonce + timestamp);</code>
<code>HttpHeaders headers = new HttpHeaders();</code>
<code>headers.set("AppId", appId);</code>
<code>headers.set("Nonce", nonce);</code>
<code>headers.set("Timestamp", timestamp);</code>
<code>headers.set("Signature", signature);

Risk Assessment & Emergency Plan

Key risks include key leakage, man‑in‑the‑middle attacks, replay attacks, and configuration errors. Mitigations involve KMS‑backed key rotation, mutual TLS, nonce‑timestamp checks, and centralized configuration management. Emergency steps:

Revoke the compromised AppId.

Notify partners to stop sending requests.

Issue new keys and certificates.

Analyze logs for forensic investigation.

Recommended Technology Stack

Certificate Management: OpenSSL, cert‑manager

Key Management: Vault, KMS

Log Auditing: ELK, Loki

SDK Distribution: Maven, Go Modules

Cryptographic Algorithms: RSA‑2048, AES‑256, HMAC‑SHA256

Conclusion

"This is not just an encryption scheme; it is a complete security ecosystem. By combining transport security, request signing, data encryption, key management, and audit logging, we build a truly closed‑loop security solution that can withstand even finance‑grade audits."