Triggerfish, also known as cell-site simulators or digital analyzers, are nothing new: the technology was used in the 1990s to hunt down renowned hacker Kevin Mitnick. By posing as a cell tower, triggerfish trick nearby cell phones into transmitting their serial numbers, phone numbers, and other data to law enforcement. Most previous descriptions of the technology, however, suggested that because of range limitations, triggerfish were only useful for zeroing in on a phone's precise location once cooperative cell providers had given a general location.

This summer, however, the American Civil Liberties Union and Electronic Frontier Foundation sued the Justice Department, seeking documents related to the FBI's cell-phone tracking practices. Since August, they've received a stream of documents—the most recent batch on November 6—that were posted on the Internet last week. In a post on the progressive blog Daily Kos, ACLU spokesperson Rachel Myers drew attention to language in several of those documents implying that triggerfish have broader application than previously believed.

The researchers from the Security and Cryptography Laboratory at Ecole Polytechnique Federale de Lausanne are able to capture keystrokes by monitoring the electromagnetic radiation of PS/2, universal serial bus, or laptop keyboards. They've outline four separate attack methods, some that work at a distance of as much as 65 feet from the target.

In one video demonstration, researchers Martin Vuagnoux and Sylvain Pasini sniff out the the keystrokes typed into a standard keyboard using a large antenna that's about 20 to 30 feet away in an adjacent room.

Website here.

(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 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…

• Wikipedia - Pseudo-random Number Generator
• Wikipedia - Hardware Random Number Generator
• NIST - Random Numbers Page
• Netscape RNG Attack
• van Heusden Video Rand

Cheers, Erik

Art of Information Security would love your feedback !

Got Entropy ?

One point the report makes which I found very interesting is the distinction it draws between "domain tasting" and "domain kiting." I've frequently seen the two terms used interchangeably, or at least in a way that engendered confusion. The report draws a sharp distinction. The definition for domain tasting they give is:

A monetization practice employed by registrants to use the AGP to register domain names in order to test their profitability. During this period, registrants conduct a cost-benefit analysis to see if the tested domain names return enough traffic to offset the registration fee paid to the registry over the course of the registration period (e.g., currently $6 for a .NAME domain name).

A form of domain tasting which involves continual registration, deletion, and re-registration of the same names in order to avoid paying the registration fees. This practice is sometimes referred to as "domain kiting." This term has been mistakenly used as being synonymous with domain tasting, but it refers to multiple and often consecutive tasting of the same domain name that avoids paying the registration fee. N.B. there is no guarantee that a registrant who allows a name to drop at the end of the AGP will be successful in re-registering it as other registrants may also compete for the same name.

This clears up a lot for me.