Here's the actual policy:

Federal agents may take a traveler's laptop or other electronic device to an off-site location for an unspecified period of time without any suspicion of wrongdoing, as part of border search policies the Department of Homeland Security recently disclosed. Also, officials may share copies of the laptop's contents with other agencies and private entities for language translation, data decryption, or other reasons, according to the policies, dated July 16 and issued by two DHS agencies, US Customs and Border Protection and US Immigration and Customs Enforcement... DHS officials said that the newly disclosed policies — which apply to anyone entering the country, including US citizens — are reasonable and necessary to prevent terrorism... The policies cover 'any device capable of storing information in digital or analog form,' including hard drives, flash drives, cell phones, iPods, pagers, beepers, and video and audio tapes. They also cover 'all papers and other written documentation,' including books, pamphlets and 'written materials commonly referred to as "pocket trash..."

It's not the policy that's amazing; it's the fact that the government has actually made it public.

Slashdot thread. My previous essay on crossing borders with laptops, and how to protect yourself.

Although honestly, the best thing is probably to keep your encrypted archives on some network drive somewhere, and download what you need after you cross the border.

Ostensibly this purchase allows JetBlue a faster and simpler path into operations. Whether it's worth it to JetBlue is hard to tell, except that they will likely be marketing this service to other airlines as a differentiator. It will be lower bandwidth than AirCell, but could be likewise cheaper and used for shorter-haul flights.

Verizon notes some of the technical details of their service's business status on a FAQ for their corporate customers, which has an oddly large amount of business detail. Verizon was obligated within two years of the end of the auction for the spectrum they occupied with their very inefficient narrowband analog service to cease operations on those frequencies. That date is about now (the certification of the auction results was close to two years ago), and Verizon clearly worked out the details to allow current customers to maintain continuity through the spectrum vacation and into JetBlue's hands on January 1.

As I noted a few days ago, a few sources had already tipped me that JetBlue's test aircraft with Wi-Fi onboard and email was using the ancient Airfone network, which is capable of slow dial-up modem speeds, rather than using the 1 MHz which could conceivably carry over 500 Kbps of data in each direction per plane.

JetBlue won a sliver of air-to-ground spectrum in auctions in 2006 through their LiveTV division. This should allow them to offer low-speed services, including email.

However, a little birdie told me that JetBlue's test is using the old analog cell network downlinks--that's right, 1990s technology that provides a trickle of bandwidth. This is what the Tenzing JetDirect service, briefly available before the airline industry collapsed, used for connectivity.

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

In the physical world we have all grown to understand that there are many types of security solutions that are needed to secure your environment.  We purchase products like Switches with ACL's, Firewalls, Intrusion Prevention Devices, Patch Management Appliances, Network Access Control appliances and many times we for go "best of breed" and go for the "all in one" approach and deploy UTM devices.

So what has changed for the virtual environment?  Nothing really.  Those same types of choices and things need to be looked at and considered.

But!  The Vendor community would lead you to believe that you don't need various types of security products in your virtual environment.  They would also lead you to believe that you only need their solution.  In fact, they all compete against each other to some extent. 

I'm sure if you were to ask Reflex who their competitors were, they would tell you Blue Lane and Catbird, or if you were to ask Catbird who their competitors were, they would say Blue Lane and Reflex.  I know this because I use to site these companies as competitors myself while serving as the Chief Product Officer at Reflex Security.

As a vendor we spend so much time trying to show our value that we loose sight of the real value of security solutions working together to provide a comprehensive and secure solution vs. a single point solution.

Think about this for a moment.  None of the following vendors really compete with each other, in fact they can complement each other:

Blue Lane - Provides Inline Patch Management
Reflex Security - Provides Intrusion Prevention
Montego Networks - Provides Secure Switching (Firewalling + Switching)

Still Secure - Provides IPS
Catbird - Provides IPS

Now, you can say Reflex, Catbird and Still Secure compete but the rest are very different.

The real question is how do you deploy a Firewall, Patch Management and Intrusion Prevention products in your virtual environment.  Well, one way is to deploy them in "series" and each product will require a dedicated virtual switch.  Take a look at the picture bellow and you will see how messy the design looks:

<-- Click to Enlarge

Each time a packet has to enter and leave a vSwitch you will experience some performance degradation; however this is a requirement by VMWare if you want to install "guest-based" security appliances. 

This  security product to vswitch, to security product, to vswitch is very much like an A/D (analog to digital) conversion that takes place on  digital networks.  Each time you make an A/D conversion you introduce  noise and noise introduces signal loss, which introduces poor performance or sound quality.

Not to mention its just really messy looking!

So, how does one deploy the security products one needs in the virtual environment without causing a performance challenge and how do we get the vendors to stop competing and start joining forces to deliver solutions that work together?

Well, one way of doing this is to put some intelligence in the switching architecture so that it can play "traffic cop" and send traffic to the needed security applications.  This type of design would be security in parallel vs. in series.  Take a look at the bellow graphic and it will be more clear:

<-- Click to Enlarge

You'll also note from this picture that the Security Switch in the center is already able to see VM to VM communication and by it playing traffic cop as well as switch and firewall it can also extend its VM to VM capabilities to security products that do not have that ability.

In the previous picture, products were deploed in series and there was no VM to VM Patch Management, or VM to VM Intrusion Prevention or VM to VM Network Access Control.  What you were able to get was VM to Physical Patch Management, Intrusion Prevention, etc.

With a product such as a Virtual Security Switch you get VM to VM everything hooked up to the Security Switch. 

What a concept!  Companies partnering to provide a comprehensive security solution.  No competing, each company focuses on their core competencies and works together to give customers what they really need.

Think about it, does McAfee compete with NetScreen?  Did Checkpoint compete against Tipping Point back in the early days?  No, we had Firewalls, Anti-Virus, Intrusion Prevention products all co-existing and many of these vendors partnered with Extreme and Foundry since they were the connectivity point of the network.

I think the virtual network is no different, so vendors, please stop confusing the market and telling customers they only need IPS, or only need Firewall, or only need Patch Management.  What customers need is choice and the ability to have the products they choose co-exist without causing major performance and management challenges.

-JP

In the physical world we have all grown to understand that there are many types of security solutions that are needed to secure your environment.  We purchase products like Switches with ACL's, Firewalls, Intrusion Prevention Devices, Patch Management Appliances, Network Access Control appliances and many times we for go "best of breed" and go for the "all in one" approach and deploy UTM devices.

So what has changed for the virtual environment?  Nothing really.  Those same types of choices and things need to be looked at and considered.

But!  The Vendor community would lead you to believe that you don't need various types of security products in your virtual environment.  They would also lead you to believe that you only need their solution.  In fact, they all compete against each other to some extent. 

I'm sure if you were to ask Reflex who their competitors were, they would tell you Blue Lane and Catbird, or if you were to ask Catbird who their competitors were, they would say Blue Lane and Reflex.  I know this because I use to site these companies as competitors myself while serving as the Chief Product Officer at Reflex Security.

As a vendor we spend so much time trying to show our value that we loose sight of the real value of security solutions working together to provide a comprehensive and secure solution vs. a single point solution.

Think about this for a moment.  None of the following vendors really compete with each other, in fact they can complement each other:

Blue Lane - Provides Inline Patch Management
Reflex Security - Provides Intrusion Prevention
Montego Networks - Provides Secure Switching (Firewalling + Switching)

Still Secure - Provides IPS
Catbird - Provides IPS

Now, you can say Reflex, Catbird and Still Secure compete but the rest are very different.

The real question is how do you deploy a Firewall, Patch Management and Intrusion Prevention products in your virtual environment.  Well, one way is to deploy them in "series" and each product will require a dedicated virtual switch.  Take a look at the picture bellow and you will see how messy the design looks:

<-- Click to Enlarge

Each time a packet has to enter and leave a vSwitch you will experience some performance degradation; however this is a requirement by VMWare if you want to install "guest-based" security appliances. 

This  security product to vswitch, to security product, to vswitch is very much like an A/D (analog to digital) conversion that takes place on  digital networks.  Each time you make an A/D conversion you introduce  noise and noise introduces signal loss, which introduces poor performance or sound quality.

Not to mention its just really messy looking!

So, how does one deploy the security products one needs in the virtual environment without causing a performance challenge and how do we get the vendors to stop competing and start joining forces to deliver solutions that work together?

Well, one way of doing this is to put some intelligence in the switching architecture so that it can play "traffic cop" and send traffic to the needed security applications.  This type of design would be security in parallel vs. in series.  Take a look at the bellow graphic and it will be more clear:

<-- Click to Enlarge

You'll also note from this picture that the Security Switch in the center is already able to see VM to VM communication and by it playing traffic cop as well as switch and firewall it can also extend its VM to VM capabilities to security products that do not have that ability.

In the previous picture, products were deploed in series and there was no VM to VM Patch Management, or VM to VM Intrusion Prevention or VM to VM Network Access Control.  What you were able to get was VM to Physical Patch Management, Intrusion Prevention, etc.

With a product such as a Virtual Security Switch you get VM to VM everything hooked up to the Security Switch. 

What a concept!  Companies partnering to provide a comprehensive security solution.  No competing, each company focuses on their core competencies and works together to give customers what they really need.

Think about it, does McAfee compete with NetScreen?  Did Checkpoint compete against Tipping Point back in the early days?  No, we had Firewalls, Anti-Virus, Intrusion Prevention products all co-existing and many of these vendors partnered with Extreme and Foundry since they were the connectivity point of the network.

I think the virtual network is no different, so vendors, please stop confusing the market and telling customers they only need IPS, or only need Firewall, or only need Patch Management.  What customers need is choice and the ability to have the products they choose co-exist without causing major performance and management challenges.

-JP

My prediction for 2008 is that confusion will reign because part of the answer is provided by cable, satellite, or telephone service companies, and their incentive is to maintain confusion because that’s an effective “up-sell” technique.

The simple story is that over-the-air (OTA) analog goes away, replaced by OTA digital. For OTA consumers, it’s just a matter of getting an ATSC tuner (built-in to a newer TV, or standalone with a government-subsidizied coupon).

The part that is different for every locality and service provider: what to do with analog TVs on analog cable systems. For every locality there is a simple cable story: the cable company could tell you their plans for analog channels, e.g. “We’ll continue to carry local channels for our analog customers through [let’s say] 2012.” But the cable companies will generally avoid that story. (I tried to extract it from TWC and they failed the first test, answered the wrong question entirely.)

Why would they tell you a simple “analog on cable is OK for N years” story when they would rather upgrade you to a new digital cable set-top box, and while they’re at it, try to replace your phone too?

So, even if it’s true that analog cable customers will live just fine on the analog cable plant for quite some time, you’ll only see it either in extremely fine print, or omitted as a choice at all in most promotional materials.

Now, it is also true that for bandwidth utilization reasons, the cable companies would like to convert their cable plant to all-digital. If they somehow manage to convert all their cheap $8/month basic cable customers to some fatter bundle, all the better for them. The good thing is that digital OTA tuners will provide competition, so the cable company had better have something that competes with free digital for cheap customers, or they’ll just lose the low end altogether. (The only reason I have basic cable is because my analog OTA reception is poor. Once digital OTA becomes cheap (it’s not yet, standalone tuners are too expensive), I’ll be a digital OTA customer unless cable really makes it worthwhile not to switch. It’s a race to the bottom for my dollar.)

Once they start losing a significant number of customers to digital OTA, then they will start publicizing cheap basic analog and constructing cheap basic digital. But they will wait as long as possible.