Category Archives: Cryptography

((AoIS Webcast)) Cryptography: Issues and Insight from Practical Implementations

Kevin Flanagan and I delivered a presentation on Cryptography at this year’s RSA 2010. Now, doing a cryptography presentation at RSA is a bit like putting a target on yourself that says “please shoot me down!”. Well, the presentation was very well received, and the RSA conference folks have asked Kevin and I to do a encore presentation via Webcast.  A few quick facts:

This is not your math teacher’s Cryptography presentation !
The core of this presentation is about discussing the various points in an application where a cryptographic control, primarily encryption, can be applied. Kevin and I walk through an expanded version of the 3-tier application architecture. We go beyond discussing the encryption controls available to the web server, application server, and database backends, to expand our scope to include the PC, storage, backup, and file systems. At each point we will discuss the kinds of controls that can be applied, the risks that those controls help manage, and risks which are ofttimes overlooked and remain.

This presentation is more focused than the RSA Version from March.
In our presentation in March we tried to also include an introduction to Key Management. This proved to be too much to bite off, so we have pruned that material from the presentation that is planned for the Webcast. Kevin and I may be submitting a presentation proposal for RSA 2011, 100% dedicated to Key Management. (Feedback on that idea would be of great value… Feel free to comment below.)

In fact, I am always interested in feedback from readers of AoIS. So, if you tune in the the WebCase, please drop me a note. I personally find web and teleconference presentations much more difficult than in the in-person kind…

When and Where ?
The Webcast in this Wed (June 23, 2010) at 1:00 PM EST, 10:00 AM PST, 5:00 PM GMT.
Here is a link to the registration: Webcast: Cryptography: Issues and Insight from Practical Implementations

Cheers, Erik

Crypto: Kerckhoffs’ Principle

Kerckhoffs’ Principle is one of the keys to solid cryptographic security. Here is the definition I found on the Wikipedia:

“A Cryptosystem should be secure even if everything about the system, except the key, is public knowledge.”

Kerckhoffs’ Principle does not require that we publish or disclose how things work. It does require that the security of the system must not be negatively impacted by such a disclosure. A sub-theme of this principle, is that if the system is not negativly impacted by disclosure, it may be enhanced. 

In the history of cryptographic systems, peer reviewed systems/algorithms/techniques have outperformed closed/proprietary ones. This has its roots in basic human nature and is demonstrated every day in basic quality controls used for software in general.

A coworker once pointed out, “I am very confident that I can build a system that I cannot break. I am not so confident that I can build a system that no one else can break.” Getting many “someone else” resources to look at things is the core of Kerckhoffs’ Principle in practice, even if not in original intent. An example of using Kerckhoffs’ Principle is the current effort by NIST to sponsor the development and adoption of the next generation of hash algorithms through their hash contest (wiki, NIST). 

If You Need to Keep the “How” Secret…

If you need to keep the “how” secret, then odds are it isn’t a very good approach to the problem (and you may know that). I am often shocked when probing people on password protection, at how often their not wanting to disclose this information (because it is a “secret” itself) correlates to a very poor practice. 

BTW: the most frequent bad practice that I encounter over and over again is that “Base64 Encoding” is being used to “protect” the password. If I built a system that did that, I too would want to keep it a secret… 😉

(In this case, I think the reluctance to disclose the information aligns more with “cover up” than “system design secret”.)

Kerckhoffs’ First Benefit: Peer Review and Collective Experience
(aka Not Being Dependent on Cleverness over Knowledge…)

It often seems odd to people that there are no secrets about how modern cryptographic algorithms are designed, operate, and are selected for broad usage.  Of course, I think many of these people don’t understand that this is no different from most security controls. Anyone can purchase a high-security lock, and then reverse engineer the lock. Take it apart, put it back together again, take it apart and examine (or replicate) each part, and so on. People’s trust in locks often greatly exceeds the actual “security” provided by the lock, but that has nothing to do with the fact that people have examined them. Most frequently it has more to do with people just purchasing cheap locks. 

Kerckhoffs’ Second Benefit: You Can Stand on The Shoulders of Giants

Back to passwords… Let’s say you are writing an application, and you need to store user account passwords. You are in luck – you can examine a broad body of work documenting the failures and redesigns of a number of password systems – and you can emulate what is working today without repeating old mistakes. The same can be said for a great number of security functions. 

It often amazes me how often people start with the blank page and reinvent the wheel. Personally, I don’t ever want to re-invent the wheel. If I do that, I will be lucky if I develop the wheel for a Roman ox cart, or bicycle. I would rather take what I can find out about the wheel and take it to the next level (maybe Formula 1 Ferrari Team Wheels…), or be done with that part of the system design quickly and focus on something more challenging. 

Kerckhoffs’ Third Benefit: Standards

Any time you are developing a solution to a problem and you can leverage a standards approach you are gaining numerous benefits. First, you are leveraging the “Standing on the Shoulders of Giants” concept by inheriting a body of work that has been tested, reviewed, etc. Second, it is easier to communicate it to others.

In the cryptographic world, there are a number of very helpful standards bodies. These include:

More soon…

Cheers, Erik

Secure Your Linux Host – Part 2: Secure SSH

SSH is the preferred (perhaps de facto) remote login service for all things UNIX. The old-school remote login was telnet. But telnet was completely insecure.  Not only was the confidentiality of the session not protected, but the password wasn’t protected at all – not weak protection – no protection.

Trinity hacking ssh with nmap in ReloadedAnd so SSH (aka Secure Shell was developed)… But it has not been without its failings. There are two “flavors” for SSH: Protocol 1 and 2.  Protocol 1 turned out to have pretty serious design flaws. The hack of SSH using the Protocol 1 weaknesses was featured in the movie Matrix Reloaded. So, by 2003, the flaws and the script kiddie attack were understood well enough to have the Wachowski Brothers immortalize them.

Another concern to watch out for is that SSH has port-forwarding capabilities built into it. So, it can be used to circumvent web proxies and pierce firewalls.

All in all though, SSH is very powerful and can be a very secure way to remotely access either the shell or (via port forwarding) the services on your host.

For additional information on SSH’s port-forwarding capabilities:

Be aware that SSH is part of a family of related utilities; check out SCP, too.

Configuration

After installing the SSH server (perhaps: apt-get install openssh-server), you will want to turn your attention to the configuration file /etc/ssh/sshd_config

Here are a few settings to consider:

Protocol 2
PermitRootLogin no
Compression yes
PermitTunnel yes
Ciphers aes256-cbc,aes256-ctr,aes128-cbc,aes192-cbc,aes128-ctr
MACS hmac-sha1,hmac-sha1-96
Banner /etc/issue.net

  1. The “Protocol” setting should not include “Protocol 1”. It’s broken; don’t use it.
  2. PermitRootLogin should never be “yes” (so, of course that is the default !). The best option here is “no”, but if you need or want to have direct remote root access (perhaps as a rescue account), then the “nopwd” option is better than “yes”. The nopwd option will force you to set up and use a certificate to authenticate access.
  3. Unless your host’s CPU is straining to keep up, turn on compression. Turn it on especially if you are ever using a slow network connection (and who isn’t).
  4. If you are not going to access services remotely using SSH as sort of a micro-VPN, then set this to “off”.  Because I use the tunneling feature, I have it turned on.
  5. OK; I work and consult on cryptographic controls, so I restrict SSH to the FIPS 140-2 acceptable encryption algorithms.
  6. Likewise, I restrict the Message Authentication Codes (MACS) to stronger hashes.
  7. Some jurisdictions seem to not consider hacking a crime unless you explicitly forbid unauthorized access, so I use a banner.

Sample Banner

It seems that (at least at one point in the history of law & the internet) systems which did not have a login banner prohibiting unauthorized use may have had difficulty punishing those that abused their systems. (Of course, it is pretty hard to do so anyway, but…) Here is the login banner that I use:
* - - - - - - - W A R N I N G - - - - - - - - - - W A R N I N G - - - - - - - *
*                                                                             *
* The use of this system is restricted to authorized users. All information   *
* and communications on this system are subject to review, monitoring and     *
* recording at any time, without notice or permission.                        *
*                                                                             *
* Unauthorized access or use shall be subject to prosecution.                 *
*                                                                             *
* - - - - - - - W A R N I N G - - - - - - - - - - W A R N I N G - - - - - - - *

Account Penetration Countermeasures

Within hours of establishing an internet accessible host running SSH, your logs will start to show failed attempts to log into root and other accounts. Here is a sample from a recent Log Watch report:

--------------------- SSHD Begin ------------------------
Failed logins from:
58.222.11.2: 6 times
211.156.193.131: 1 time
Illegal users from:
60.31.195.66: 3 times
203.188.159.61: 1 time
211.156.193.131: 3 times
Users logging in through sshd:
myaccount name:
xx.xx.xxx.xx: 3 times
---------------------- SSHD End -------------------------

One of the most effective controls against password guessing attacks is locking out accounts after a predetermined and limited number of password attempts. This has a tendency to turn out to be a “three strikes and you’re out” rule.

The problem with applying such a policy with a remote service, like SSH, as opposed to your desktop login/password, is that blocking the password guessing attack becomes a Denial of Service attack. Any known (or guessed) login ID on the remote machine will end up being locked out due to the remote attacks.

Enter Fail2ban: Rather than lock out the account, Fail2ban blocks the IP address. Fail2ban will monitor your logs, and when it detects login or password failures that are coming from a particular host, it blocks future access (to either that service or your entire machine) from that host for a period of time. (Oh, and you may notice I said blocks access to the “service”, and not “SSH” – that’s because Fail2ban can detect and block Brute Force Password attacks against SSH, apache, mail servers, and so on…)

How to Forge has a great article on setting up Fail2ban – Preventing Brute Force Attacks With Fail2ban – check it out.

One tweak for now. As I tend to use certificate authentication with SSH (next topic), I rarely am logging in with a password. As a result, I tend to use a bantime that is long, ranging from a few hours on up. Three guesses every few hours really slows down a Brute Force Attack! Also, check out the ignoreip option, which can be used to make sure that at least one host doesn’t get locked out. (You can lock yourself out with Fail2ban… I have done it…)

SSH Certificate Based Authentication Considerations

Secure Shell offers the ability to use certificate based authentication with a self-signed certificate. There are two ways you might consider using this:

  1. With a password protecting the private key
  2. With no password required

Please note: When you establish certificate based authentication with SSH, you will generate a public/private key pair on your local computer. The public key will only be copied up to the server which you wish to access. The private key always stays on your local computer.

During the process of generating the private and public key pair, you will be asked if you want to password protect the private key. Some things to consider:

  • Will this ID be used for automated functional access ?

If you are creating the certificate based authentication so that a service can access data or run commands on the remote machine, then you will not want to password protect the local file. (If you do, you will end up including the password in the scripts anyway, so what would be the point?)

Personally, I have backup scripts which either pull data or snapshots on a regular basis. Google “rsync via ssh” for tips on this, or “remote commands with ssh” for tips and ideas. (Also, I may cover my obsessive compulsive backups in a later post.)

  • This ID will be used for a rescue account

In this case the certificate is usually created to avoid password expiration requirements. If it is a rescue account, it often logs into root. Any time you use certificate access for root, the private key should be password protected. Rescue accounts are often stored on centralized “jump boxes” and are expected to only be used during a declared emergency of some kind (such as full system lockout due to a password miss-synchronization.)

These private keys should always be password protected.

If someone has access to backups or disk images of the jump box, or otherwise gets access to your .ssh directory, and you have not password protected the private key, then they own the account (e.g., they can use the public/private key pair from any box).

  • Convenient remote logons…

The most common use of certificate based authentication for SSH is in fact to log you into the remote box without having to type passwords. (I do this, too…) But there are a few things to think about (these are all good general recommendations, but I consider them requirements when using an automated login…)

  1. Automatic login should never be used on a high-privilege account (e.g., root)
  2. If those accounts have sudo privileges, sudo should require a password
  3. A new certificate (public and private key pair) should be created for each machine you want to access the remote server from (e.g., desktop, laptop, etc.).  Do not reuse the same files.
  4. The certificate should be replaced occasionally (perhaps every 6 months).
  5. Use a large key and use the RSA algorithm option (e.g., ssh-keygen -b 3608 -t rsa)

SSH Certificate Based Authentication Instructions

So, without further ado… Let’s set up a Certificate for authentication.

Part 1 – From the client (e.g. your workstation, etc…)

First, confirm that you can generate a key.

$ ssh-keygen --help

The options that are going to be of interest are:

  • -b bits  Number of bits in the key to create
  • -t type  Specify type of key to create

DSA type keys, you will note, have a key length of exactly 1024. As a result, I choose RSA with a long key. My recommendation is that you take 2048 as a minimum length. I am pretty paranoid, and I have a strong background in cryptography, but I have never used a key longer than 4096.

The longer the key, the more math the computer must perform while establishing the session. After the session is established, then one of the block-ciphers discussed above performs all of the crypto. If you are making a key for a slow device (like a PDA) or a microcontroller based device, then use a shorter key length. Regardless, actually changing the keys regularly is a more secure practice than making a large one that is never changed.

$ ssh-keygen -b 3608 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/erikheidt/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/erikheidt/.ssh/id_rsa.
Your public key has been saved in /Users/erikheidt/.ssh/id_rsa.pub.
The key fingerprint is:
43:69:d8:8e:c4:af:f8:8b:5a:2d:db:75:91:fd:06:be erikheidt@Trinity.local
The key's randomart image is:
+--[ RSA 3608]----+
|                 |
|     . o .       |
|      + =        |
|     . *   o     |
|      . S o o    |
|     o . . o o   |
|    + o . . . o  |
|   . * . .   o   |
|  ..o +.    E    |
+-----------------+

Now, make sure your .ssh directory is secured properly…

$ chmod 700 ~/.ssh

Next, you need to copy the public key (only) to the server or remote host you wish to login to.

$ cd ~/.ssh

$ scp id_rsa.pub YourUser@Hostname

Now we have copied the file up to the server….

Part 2 – On the Server or remote host….

Logon to the target system (probably using a password) and then set things up on that end…

$ ssh YourUser@Hostname

$ mkdir .ssh
$ chmod 700 .ssh
$ cat id_rsa.pub >> ~/.ssh/authorized_keys

Done ! Your next login should use certificate based authentication !

I hope this posting on SSH was useful.

Cheers, Erik

Got Entropy ?

So I have been planning a series of podcasts on Cryptographic Controls. In the process of this planning, I fell into one of the classic traps that crypto-geeks fall into: obsessing about random number generators (RNGs).

(FYI, for the impatient, click here.)

There are two ways to generate random numbers on computers: (1) use a software program called a Pseudorandom Number Generator (PRNG) or (2) use a hardware random number generator. A Pseudorandom Number Generator uses a seed value to generate a sequence of numbers that appear random. The problem is that the same seed generates the same random sequence. The hardware based RNG observes and samples some physical phenomenon which is random, such as cosmic rays, RF noise, etc. (aka Entropy).

RNGs are important in Information Security because they are used to generate encryption keys, salts, etc. Historically, attacking RNGs has proven effective, such as the defeat of Netscape’s HTTPS sessions.

Most operating systems utilize a hybrid approach, implementing a PseudoRandom Number Generator that has a seed that is regularly updated through the collection of random hardware events. This process is called Entropy Collection or Entropy Harvesting. For most applications, this approach should be completely sufficient. However, one of the key assumptions is that the operating system has been up and running long enough for the seed value itself to become hard to predict through the collection of Entropy. Also, many of the Entropy collecting events come from properties of hardware devices, such as the minor variations in hard drive rate of rotation. As such, there are a few circumstances where the OS RNG may not be good enough for strong cryptographic key generation:

  • Live Boot CD ( The start state of the RNG may be predictable. )
  • Virtualized Hosts ( OS may be dependent on simulated events for randomness. )

( Given the exploding popularity of virtualization, this is an area worthy of research. Stay tuned. )

Design of the Got Entropy Service

Many RNGs (such as the one included in Linux, as well as OpenSSL’s) allow the addition of entropy from outside sources. So I started looking to Entropy sources I could use to bolster the RNGs on my virtual hosts (and other uses…). While I was looking into this, it occurred to me that I had an unused TV tuner card, a PVR-350.

When a TV is tuned to a channel with no local station, the ‘snow’ on the screen is RF noise (the same as the static between stations on AM radios). But, for reasons beyond our scope, you never use a direct physical observation as the RNG. You have to ‘de-skew and whiten’ the data prior to sampling it. Here is the process that I use:

  1. Collect about 3 minutes of video ( about 130 MB data ).
  2. Using a random key and IV, encrypt the data ( using openssl & AES-128-CBC ).
  3. Discard the first 32k of the file.
  4. Use each of the following 32k blocks as samples.
  5. Compress each sample with SHA-256.
  6. Discard the last block.
  • Steps 2 and 3 remove any patterns, such as MPEG file formatting, from the data.
  • Steps 4 and 5 generate a 32-byte random value ( 1024 to 1 compression in the hash ).

Check it out at http://gotentropy.artofinfosec.com

Can an Attacker Broadcast a Signal to Undermine This?

Such an attacker could not remove RF noise from the received signal. Our eyes and brains are good at filtering out the noise in the TV video, but there is a lot of it. Part of the noise comes from the atmospheric background RF, but there are also flaws (noise) in the tuner’s radio and analog-to-digital capture circuitry.

I think this is a pretty strong RNG, and I have provided an interface for pulling just the values.

Also, I have written a script ( getEntropy.sh ) that will pull Entropy from the service and seed it into /dev/random on Linux.

Results from ENT

Here are results, from a sample run of the Got Entropy, analyzed by ENT ( A Pseudorandom Number Sequence Test Program provided by John Walker of http://www.fourmilab.ch – Thanks, John! ).

  • Entropy = 7.999987 bits per byte
  • Optimum compression would reduce the size of this 13366112 byte file by 0 percent.
  • Chi square distribution for 13366112 samples is 233.85, and randomly would exceed this value 82.48 percent of the time.
  • Arithmetic mean value of data bytes is 127.4767 (127.5 = random).
  • Monte Carlo value for Pi is 3.143054786 (error = 0.05 percent).
  • Serial correlation coefficient is -0.000078 (totally uncorrelated = 0.0).

Resources for the Curious…

Cheers, Erik

What do you want to know about Cryptography in the Enterprise ?

I am working on a presentation entitled “Lessons Learned Deploying and Managing Enterprise Cryptosystems“. I will be presenting this at Information Security World 2008. In the 45 minutes I have for the presentation, it is my goal to touch on several key lessons learned in my work with cryptographic controls over the past several years. Cryptosystems is a broad topic, and can include not only techniques (encryption, digital signatures, timestamps), but also key management and implementation issues. There is a lot of material that I have available to draw from, and I want to make sure that the presentation includes the most valuable and relevant points that it can. After giving a presentation, there is almost nothing more disappointing than reviewing the feedback forms only to find out what people really wanted to know. This is especially disappointing if it is material you could have easily included…

I would love to know what kinds of questions you have and would like to see addressed.

In addition to your question, please provide a little context, such as:

– What are the drivers for your use of cryptographic controls (data protection, compliance, etc.)?
– Will your deployment be externally audited?

Cheers,
Erik

Cross posted on Linked In.