Encryption in Transit and at Rest, Key Management and HSMs

Encryption in transit protects payment data while it moves between systems. When a customer submits a payment through a banking portal, the browser and the server use TLS to encrypt the connection, so that an attacker on the same network cannot read the account number, amount or beneficiary details. When a bank sends a pacs.008 to SWIFT, the message travels over a secure network with encryption and authentication. If encryption in transit is missing or uses an old version of TLS, the data can be intercepted, read or altered, and the bank may not even know that it happened. Encryption at rest protects payment data when it is stored in a database, a file or a backup. A database that holds customer account numbers, payment instructions and transaction history must encrypt sensitive fields, so that a stolen disk or a copied backup does not expose the data in readable form. A payment file stored on a shared drive must also be encrypted or access controlled. Encryption at rest does not replace access control, it adds a second layer, so that even if an attacker gains access to storage, the data remains unreadable without the correct key. Key management is the discipline that makes encryption work, and it is where many systems fail. An encryption key is a secret value, and if it is stored in plain text in source code, in a configuration file, or in an email, the encryption is worthless. Keys must be generated securely, stored separately from the data they protect, rotated on a schedule, and revoked when they are no longer trusted. A bank that encrypts a 1 million pound payment instruction with a key that is visible in a public code repository has not protected the payment at all, it has only hidden it behind a secret that is no longer secret. A Hardware Security Module, known as an HSM, is a dedicated device that generates, stores and uses cryptographic keys inside tamper resistant hardware. The private key never leaves the HSM, and operations such as signing a payment file or decrypting a message happen inside the device. If someone tries to open the HSM, it detects tampering and destroys the keys. Banks use HSMs for SWIFT message signing, for card payment processing, and for protecting master keys. An HSM does not make a system secure on its own, but it removes the risk that a key can be copied from a server or a laptop. A security reviewer should check the full encryption picture, not only one part. The reviewer asks which data is encrypted in transit and at rest, which algorithm and key length are used, where keys are stored, who can access them, how often they are rotated, and what happens when a key is compromised. The reviewer also checks that old TLS versions are disabled, that certificates are valid, and that test data is not encrypted with production keys. Encryption is only as strong as its weakest link, and in payments that weak link is usually key management, not the algorithm itself. TLS version matters, and old versions are a live vulnerability. TLS 1.0 and TLS 1.1 have known weaknesses and must be disabled; TLS 1.2 is the minimum, and TLS 1.3 is preferred because it removes outdated cipher suites and speeds up the handshake. A payment API that still accepts TLS 1.0 is exposed to downgrade attacks, where an attacker forces the connection to use the weaker protocol. A security reviewer should test the API with an old TLS client and confirm that the connection is refused. The review should also confirm that the certificate is valid, issued by a trusted authority, and uses a key length of at least 2048 bits for RSA or 256 bits for elliptic curve. Key rotation is the discipline that keeps encryption working over time. An encryption key that is never rotated becomes a bigger target the longer it lives, because an attacker who steals it can decrypt everything encrypted with it. A good rotation policy changes data encryption keys annually and key encryption keys every two to three years, and it does so without downtime, by decrypting with the old key and re-encrypting with the new one. The rotation must be tested, because a failed rotation can lock the bank out of its own data. A business analyst should always ask for the rotation schedule, the rotation procedure, and the rollback plan. Encryption without rotation is a control that decays silently.