THE ROLE OF

CRYPTOGRAPHY IN
SOFTWARE SECURITY

Ed Adams, CEO, Security Innovation

Overview
Cryptography is a mathematical science and an engineering discipline, devoted to private
communications in non-private settings. Cryptography comes from the Greek word kryptos, meaning
anything that is hidden, obscured, veiled, secret, or mysterious. While the Merriam-Webster dictionary
defines cryptography as the process of writing or reading secret messages or codes, in Information
Security cryptography has more applications than simply “writing and reading secret messages.” When it
comes to software, crypto is critically important, but also can be intimidating… and easily misapplied.

Modern software development is all about speed, and that means repurposing what others have built.
These “things” might be cloud services, pre-compiled libraries from Github, or guidance in a stack
overflow knowledgebase article. One common challenge with cryptographic code is that even if it seems
to be working, it might still be insecure; therefore, it’s important for those defining and implementing
crypto to understand the principles. It’s paramount to get crypto right from the start of each project. If
you don’t, it can be like trying to change all the plumbing and pipes in your house after it’s fully built.
Take the time to learn about hashes, algorithms, keys, and secrets management… it will be well worth
the effort.

A well-known early cipher (disguised method of communication) is the Caesar Cipher. It is a simple
substitution system, where letters of the alphabet are replaced with other letters a specific number of
characters earlier or later in the alphabet. Modern cryptography uses far more complex keys and ciphers,
but the goal is the same: to communicate information privately, even in a hostile environment.

While cryptography provides software data protection, it is undoubtedly complex and can affect system
performance. The speed of processing transactions, database performance, and network throughput are
most commonly impacted. It also comes along with some other “costs”:

• Administrative costs related to access control and key management – this entails configuring the
system to ensure that only the right users have valid keys, and that those keys and tools are renewed
when needed.
• Operational costs – for instance, systems may need access to keys at boot time, which may prevent
automatic system recovery.
• Maintenance costs – systems will need to be patched when vulnerabilities are found, algorithms may
need to be replaced, and keys will need to be rotated depending on usage patterns and the sensitivity
of the data being protected.

In order to help reduce some of the inherent costs of crypto, keep Kerckhoff’s principle in mind – only the
key should be secret. This means that the software you build should be designed so that it is secure even
if an attacker knows everything about your system, except the key. The key unlocks the secret.

Another important rule is do not create your own crypto algorithm. Available crypto algorithms have
gone through a long and arduous testing process; they are literally reviewed for years and “attacked”
(people try to crack the code without the key) to validate their robustness. Fortunately, these validated
algorithms have been built into popular libraries, like OpenSSH, so you can focus on implementation and
key management.

There are two primary places where data needs to be secured: in motion/transit and while at rest. While
both rely on cryptography (including ciphers and hashing) the implementation varies.

2
Crypto Motion – Securing Data in Transit
Unlike data at rest, which mostly uses symmetric encryption, data in motion is most
commonly secured using asymmetric cryptography. Asymmetric crypto uses two
different keys for encryption and decryption. A public key to encrypt a message,
and a private key for decryption. The private key is a completely random number
whereas the public key is derived from the private key using a mathematically
“hard” problem. The math needs to be an operation that is “easy” to perform but
“hard” to reverse (or crack.)

As stated above, the concept behind all crypto is that the math problem is easy to
solve in one direction, but virtually impossible to solve in reverse. Kind of like a
lobster trap — easy to walk into, but very difficult to escape. If you choose a large number, say 12345 and
multiply that by another large number, say 67890, the result is 838,102,050. That’s easy to calculate;
however, knowing only the result (838,102,050) it’s almost impossible to guess which two numbers were
used to generate it.

Three main types of math problems (and crypto algorithms) are used:

• Integer-based (RSA) – the general idea behind RSA is to start with a large random number and enter
that into the particular RSA math function. This produces 2 related numbers: a private and public key.
The public key can be shared and is used to encrypt messages, which can only be decrypted if you
know the private key.
• Elliptic curves (ECC) – works similarly, except the math function is an equation that describes an
ellipse. Just like RSA, the math function is easy to calculate in one direction. The advantage here (with
a more complicated math equation) is that the initial random number can be much smaller than with
RSA but yield the same level of security, i.e., difficultly to reverse engineer.
• Lattice reduction (NTRU) – takes the “hard math” problem to yet another level, basing it on the
shortest vector problem in lattice calculations. It relies on the difficulty of factoring polynomials in a
truncated polynomial ring (NTRU = nth-degree truncated polynomial.) If you want to get into
convolution multiplication and advanced lattice math, have a great time. It’s not my thing! :-)

It is useful to know the most popular implementations above: RSA (integer-based), ECC (elliptic curve
based), and NTRU (lattice reduction.) Both RSA and ECC have been proven to be susceptible to a
quantum computer brute force attack, meaning given enough time those 2 crypto systems can be
cracked (quantum computers make this almost trivial using an attack called Schor’s algorithm.) There is no
polynomial time algorithm to solve the lattice reduction problem on which NTRU is based; therefore, it is
resistant to quantum computer brute force attack.

In this guide, I focus on secure, authentic, and confidential channels. I also touch upon tampering, attacks
against protected communications, and transport layer security (TLS.)

Protected Communications

Cryptography was used originally to protect communications, and this is still one of its primary uses.
There are three types of protected communications channels:

• Authentic channel is resistant to tampering, but not necessarily resistant to disclosure.

• Confidential channel is resistant to disclosure, but not necessarily resistant to tampering.
• Secure channel is resistant to both disclosure and tampering.

3
 Disclosure Resistant Tamper Resistant
Authentic Channel �
Confidential Channel �
Secure Channel � �

Remember, cryptography can create a false sense of security if not implemented properly – and it’s tough
to get right. Let’s explore these 3 channels and discus tradeoffs between them. The total costs of any
cryptographic solution should be weighed in context of the value of the information being handled.

Authentic Channels

The integrity of the message is the first concern here; that

is, prove the message was not modified. A digital signature
or Message Authentication Code (MAC) provides that proof.

Authenticity of the sender must also be assured; that is,

verify that the sender is legitimate. This is usually validated
by a trusted 3rd-party like GlobalSign (see image to the
right). GlobalSign (known as a certificate authority or CA),
gives the sender a public key certificate to use to sign
messages so the receiver has confidence of the identity of
the sender. Asserting proof of who sent the message covers
the anti-spoofing aspects of authenticity.

The 3rd consideration for authentic channels is the

authenticity of the message, that is, the message is not a
forgery and is not a “replay” of a previous message.
Asserting proof of legitimacy verifies that a message has not
been forged. The exchange between the sender and 3rd-
party also confirms this via the certificate used.

The availability aspect of anti-tampering is ensured via

proof of delivery. However, no aspect of cryptography can
ensure the delivery and receipt of a message and prevent a
denial of service (DOS) attack by flooding a server with
duplicates of the same message. That is up to the system or
application itself.

Here’s an example from an everyday work environment:

a digitally-signed email sent with a delivery receipt request.

� Integrity is covered through the digital signature. The

digital signature verifies the authenticity of the sender
and that the message was not forged. The e-mail
application itself should have a feature to detect a replay
attack by flagging such messages as a duplicate.
� Availability is covered through the delivery receipt
generated by the mail server.

4
Confidential Channels

Confidential channels are disclosure resistant but not tamper resistant. Most network communications
channels are confidential channels. They are often called ‘secure’ channels mistakenly when they are not.

Few channels are truly secure. Creating truly secure channels is impacted most by the assurance of
availability, which is often impossible to achieve with most network protocols and physical layer
implementations. Knowing that you are working with a confidential channel and not a secure channel is
essential to understanding the risks that exist without additional processes and controls.

Let’s take another commonly known example: HTTPS (Hypertext Transfer Protocol Secure). To be a truly
secure channel, HTTPS would need to be disclosure resistant and would also need to address the
integrity of each message, the authenticity of the sender of each message, the authenticity of the
message itself against forgery and replay, and the availability of the channel. In fact, HTTPS offers no
availability assurance and weak integrity assurance; thus, HTTPS is really a confidential channel and not a
secure one.

Other channels can be either secure or confidential depending upon how they are configured. For
example, Secure Shell (SSH) mutually authenticates both ends of the channel. However, the integrity
provided depends on the protocols configured on both client and server, and the actual protocol
negotiated during connection setup. SSH also provides features to promote high availability, but, like all
network protocols, it provides only limited availability assurances. SSH connections are not necessarily
confidential, so improper configuration can results in weak or unencrypted connections.

Secure Channels

These provide a secured point-to-point connection between two systems or networks, providing
resistance to both tampering and data disclosure. You can create secure channels in several ways:

• Virtual Private Network (VPN) – this is a widely deployed mechanism that provides a secured
connection in which the remote client network appears to be a part of the host’s local network. All
communication is cryptographically protected with messages both authenticated and encrypted.
• Transport Layer Security (TLS) – crypto protocol used specifically to secure data in transit in
computing networks. TLS is sometimes called a Secure Sockets Layer (SSL) VPN, which is not an
accurate description. TLS actually replaced SSL, which should not be used anymore. TLS prevents
eavesdropping and tampering. TLS uses both symmetric and asymmetric crypto during a “handshake”
process between client and server. It uses a digital certificate for authenticity.
• Secure Shell Protocol (SSH) – widely used in the Unix and Linux worlds, SSH is used to create secure
tunnels, usually between clients and servers, and is most often applied to create a secured connection
between a client and a server that does not support any protocol-level security.
For example, an SSH tunnel can be used to provide a secure Internet Message
Access Protocol (IMAP) connection for a mail server that does not support IMAP
over SSL (IMAPS). The open-source version of SSH, OpenSSH now uses NTRU
crypto by default for key exchange.

Secure Application Protocols

Many Internet protocols were developed without considering security, and now
communication over these protocols needs to be secure. As a result, TLS has been
bolted onto original protocols to create secured client-server communication,
without having to develop new secure protocols.

5
TLS provides a simple, cost-effective means to secure an existing network protocol without the expense
of developing a new secure protocol from the ground up. Examples of where TLS has been added to
existing protocols include:

• HTTPS for HTTP

• LDAPS for LDAP
• IMAPS, POPS, and SMTPS for e-mail related protocols
• SIPS, SRTP, and SRTCP for VoIP networking
• IRCS, TELNETS, and FTPS for IRC, Telnet, and FTP

Crypto Statis – Securing Data at Rest

In the creation, operation, and maintenance of software systems, data can be stored in many places: on
physical or virtual disks, files, databases, and backups (which can take various form as well.) I discuss each
one of these below, but the concept is fairly straight forward:

• Choose an appropriate algorithm and key

• Apply the encryption to the data; and,
• Store the key in a safe place for use when you need to decrypt the data

Block vs. Stream Ciphers

For data at rest, the encrypt and decrypt key is one in the same. This is called symmetric encryption and
there are 2 varieties of algorithms used: block ciphers and stream ciphers.

• Block ciphers encrypt data in fixed-size chunks. A common option is AES (the Advanced Encryption
Standard) and it comes in various encryption chunk sizes (known as block length), e.g., 128 bits.
• Stream ciphers encrypt data one bit at a time. This is a highly secure method, but rather impractical
due to the large amount of key data it needs to work (one for every bit.) Variations have been used
with a pseudo-random number generator, and some have become popular in wi-fi security
implementations like WEP and WPA. These have some known vulnerabilities, so investigate carefully
before using.

Choosing the right symmetric crypto system may also depend on how/where your software application
will be used. Be sure to check industry regulations, privacy requirements, and other requirements as
you’re designing, implementing, and deploying your application.

Whole Disk Encryption

Cryptography is often used to encrypt storage media. Whole-disk encryption, also called “full disk
encryption,” is the most common way to do this. Most whole disk encryption schemes encrypt every
sector of the disk using symmetric encryption. The key is usually protected by encrypting it with the user’s
credentials as a passphrase. The user must enter the credentials at boot time to unlock the drive. This
passphrase is a de facto crypto key so store it in a safe place, ideally not on the very drive you are
encrypting.

Whole disk encryption is often used to protect information on laptops. However, it is often misused. In
theory, if used properly, whole disk encryption renders the contents of the laptop’s storage media
unreadable if the laptop is lost or stolen. However, for whole disk encryption to be effective, the laptop
must be powered off when not in use.

6
If the laptop is lost or stolen when in sleep or hibernation, the disk drive can be unlocked, or the
encryption key can be recovered from memory and then the disk drive can be unlocked.

In most cases, the user is the greatest weakness in deploying whole disk encryption. Many users write
passwords down and store them with their laptop; if the laptop is stolen, the user’s credentials are stolen
with it. They might also store a two-factor authentication (2FA) device, such as an RSA SecureID token, in
the same bag with their laptop. This completely negates the value of both data encryption and 2FA.

File Encryption

It’s important to encrypt individual sensitive files on all virtual or physical devices.
Failure to do so can allow an attacker to copy information onto insecure media
and/or sent through insecure communication channels, rendering the sensitive
information insecure. There are several popular tools available for encrypt/decrypt
of specific files – PGP and Zip. PGP uses both symmetric and asymmetric crypto
keys and there is an open-source version available called OpenPGP. Zip uses AES
as described above and is available for all major operating systems. You will find
numerous implementations of zip available; make note of the strength of
encryption key used. The larger the key the more secure, but also larger key sizes
make larger zip files. If storage space is at a premium in your system, this trade off
needs to be carefully considered.

Many applications also allow files to be signed with a key, reducing the risk of undiscovered tampering of
sensitive information. You sign a file for the same reason you might sign a paper document with pen – to
let readers know that you created the document or that the document has your approval. Everyone who
recognizes your signature can confirm that you wrote the letter. Similarly, when you digitally sign a file,
anyone who "recognizes" your digital signature knows that the file came from you. The process of
recognizing signatures is called verification. You can design your application so that it only uses approved
(signed) files for certain functions.

Database Encryption

Information in databases presents one of the most difficult data security issues. There are many
approaches to securing databases, and an approach that works best for one Database Management
System (DBMS) might not work for all.

Sensitive information in databases must be encrypted, but the correct approach varies with the DBMS
and the requirements of the applications processing that information. While encrypting databases solves
some problems, it can create new ones.

7
DBMS Encryption approaches & risks

Encryption Type How it works Risks

Hardware-based
Whole-disk
DBMS-based encryption
Server-side application-based
Client-side application-based
Database resides on raw partitions, separate
from the boot, file, and operating systems
Databases residing as part of the formatted file
system
Multiple techniques, e.g.,
• Transparent data encryption (TDE)
• Column-level encryption
• Field-level encryption
Sensitive data is encrypted by the application
querying the DB, and the DB has no
knowledge that the information is encrypted
Sensitive data is encrypted by the client
application, and neither the server nor DB has
any knowledge that the data is encrypted
Backup and restore needs to happen for both
the DB and the files on the non-DB partition.
Can leave backups and exported data
unsecured, because only the media itself is
secured, not the information in the database.
Solves the problem of backup and export data
being unsecured, but often leaves data
exposed to queries. So, if an attacker issues
Structured Query Language (SQL) commands
against the DB, the encrypted data in the DB
is no longer secure.
Might expose information in memory or over
the networks and can limit the ability to
perform ad-hoc queries on encrypted data.
Can create key-management issues, especially
in systems with numerous client access points.
Also, any client-side processing is susceptible
to attack, hijacking, and spoofing.

Backups

Backups are often among the largest holes in an organization’s information protection processes. They
most always contain unencrypted sensitive information, unless the information is encrypted at the file
level. For example, when using whole-disk encryption, backups of encrypted disks produce unencrypted
archives, because the unencrypted files are being backed up, not the encrypted raw disk sectors.
Similarly, backups of database transaction records and database archives themselves are unencrypted,
unless the records in the database itself are encrypted.

If you do first encrypt your data prior to backup, the primary risks are related to key management. If keys
are not managed in an "isolated system", system administrators with malicious intentions may have the
ability to decrypt sensitive data using keys that they have access to. The fundamental principle of keys
also gives rise to a potentially devastating risk: if keys are lost then the encrypted data is essentially lost
as well, as decryption without keys is almost impossible. Store your keys as carefully as you store your
backup – and keep them segregated from the backed up data the key(s) unlock.

Finally, “off-site” backups are often out of your physical control, rendering them vulnerable to
unauthorized access. Theft of backups is a common means of obtaining a path into an organization –
mainly for the reason stated above, i.e, most backed up data is unencrypted. There is no substitute for
encrypting every backup.

8
About Security Innovation
Security Innovation is a pioneer in software security and literally wrote the
book on How to Break Software Security. Since 2002, organizations have
relied on the company’s assessment and training solutions to secure
software wherever it runs. Recognized 6x on the Gartner Magic Quadrant for
computer-based security training, the company’s flagship product ,
securityinnovation.com
CMD+CTRL Base Camp, combines role-based courses with hands-on cyber
ranges to build skills that stick.

For more information, visit securityinnovation.com or connect on LinkedIn

or Twitter.