What exactly is encryption, and how does it work?

How damaging to a community bank’s reputation would it be if a visitor to its website encountered a “Not secure” warning? In an era where trust is hard to win and easy to lose, anything that puts doubt in the mind of potential customers is a dangerous thing.

Yet, following an October update to its Chrome web browser (used for 54 percent of all US internet access), there’s a chance that Google may be flagging your bank’s homepage in this way.

For years, the search giant has used a combination of warning pages and symbols in its browser to inform customers when they are sending information over connections that don’t use the secure HTTPS protocol, which is indicated by a little padlock in your browser’s address bar. (See sidebar, “Encryption decoded.”) Until now, these communications have primarily been used to warn about forms that request sensitive data such as account details and passwords. However, in this latest update, any password input boxes will be flagged as insecure if all traffic to and from that site is not protected

This may be a problem for some community banks, says Ira H. Aurit, CEO of BankSITE Services, a specialist in web development and secure hosting for banks. In the past, Aurit explains, security certificates were primarily needed for compliance on the online banking portal part of a site, which is often accessed by clicking a login button on the homepage that directs the browser to a separate server. Homepages are less likely to offer encryption because it’s not a regulatory issue.

But now, encryption is important everywhere. That’s why it pays to understand how it works.

Symmetric vs. asymmetric encryption

There are two common forms of cryptography for scrambling digital files and communications: symmetric and asymmetric encryption.

In symmetric encryption, a “key” is used in conjunction with a complex mathematical algorithm to create a coded message. The key can be a password or a long string of characters, but the same key is used to encrypt and decrypt whatever message is being sent.

For online communications, symmetric encryption presents a challenge. Both the receiver and the sender of a message (the classic cryptography textbook examples are named Alice and Bob) have to use the same encryption key. This means that at some stage, they have to share that key with each other. If this was done over the internet in such a way that they could both read it—say, in an email—an attacker would be able to intercept the key and read all future correspondence between Alice and Bob.

To get around this, we use “asymmetric cryptography,” in which the decryption key for the algorithm is different from the encryption key.

To use asymmetric encryption, Alice asks Bob for his encryption key before she sends him a message. Alice then creates her secret message using this key and sends it over the internet knowing that only someone who has Bob’s decryption key will be able to read it.

If Bob wants to reply, he’ll encrypt his message using Alice’s encryption key, so that only she can read it.

It doesn’t matter if anyone has intercepted the encryption keys while they were being exchanged; they’re useless for decoding messages. As long as Alice and Bob never share their private key with anyone, the communication is safe.

For this reason, we often call the encryption and decryption key a “public/private keypair,” “public key cryptography” or “public key infrastructure.”

When a browser initiates a secure HTTPS session with a website, it uses a mixture of symmetric and asymmetric techniques. First, it requests the server’s public key. Once it has this, the browser generates a one-off symmetric key, which it scrambles using the server’s public key and sends off to the website. Now all communication is encrypted using that unique symmetric key, which is disposed of at the end of the session.

Encryption and the regulator

Regulatory requirements mean that banks have to encrypt any sensitive data that are physically or digitally kept off-site, says Bill Bauman, one of the original employees of Ironcore.

“Backups have to be stored off-site for business continuity,” Bauman says. “And all backed-up data should be encrypted both when being transferred to a backup location and when at rest.”

As an example of the dangers of not securing and encrypting backups, Bauman cites the $1.72 trillion-asset Bank of New York Mellon, investigated in 2008 when it lost tapes containing unencrypted customer data. Many of the 4.5 million exposed records related to customers of third parties who had no direct dealings with the bank.

Mobile devices, including laptops, used by bank staff should also be encrypted by default. “The regulator will expect any device that has bank data, or has been set up to access bank data, to be protected,” Bauman says.