A few years ago, encryption was a topic discussed at the NSA or MIT, not in the corporate boardroom. Times have changed!
Given the slew of privacy regulations and publicly disclosed breaches, laptop encryption has become a must-have.
As companies buy encryption software to cover this requirement, however, another pattern is emerging. Don't let that $150 per user licensing fool you--FDE has become a commodity. The federal government negotiated a deal to pay around $15 per seat for FDE, and I've seen big deals as low as $5 per seat. To their credit, the FDE software vendors anticipated this inevitable trend and are now wrapping additional functionality around their FDE contracts to sweeten the deals and provide customers with more security. McAfee/SafeBoot bundles in Data Leakage Prevention (DLP); PointSec adds port blocking, etc.
The bottom line is that FDE alone isn't cutting it anymore; large organizations want and are willing to pay for more. This moves the FDE market in two diverse directions. On the one hand, big endpoint security vendors like McAfee, Symantec, and Trend Micro can simply make FDE a feature in their suites for cost-conscious customers and charge a few extra bucks for the favor. This makes FDE easy for the masses. On the other hand, FDE will be offered as part of much bigger and focused data security offerings. BitArmor and PGP come to mind here.
Ultimately, FDE fades into the infrastructure, embedded in Intel chips, Microsoft operating systems, and Seagate Technology hard drives. In the meantime, the remaining FDE crowd is scrambling to remain relevant. FDE as a feature in a greater data security suite is a good plan for the long term. FDE as a business opportunity is all but gone.
There is no right to privacy at international borders. For those of us with laptops, this presents a pretty major problem: How do we get through U.S. Customs with our beloved portable devices, without having Uncle Sam peeking at every e-mail we've sent, every MP3 we've listened to, and every "home movie" we've made?
The obvious solution, encryption, is not enough. Non-Americans have no right to enter the U.S. Don't want to hand over your encryption keys? No problem--but you will be put on the next airplane back to your home country (if you're lucky...If the government really doesn't like you, you may end up getting sent to Syria).
Those of us "lucky" enough to have a U.S. passport may be forced to enter the password for the data, if we want to avoid having the devices seized and never returned.
For travelers heading to countries other than the U.S., it can be even worse. Refusing to hand over your encryption key to a lawful request by British Police can result in jail time. Ouch.
CNET News.com's Declan McCullagh posted a guide to securing laptops for border searches back in March. The Electronic Frontier Foundation's Jennifer Granick wrote a blog post on the subject recently, in which she broke down the case law and offered a bit of advice. While both of these are interesting reads, neither includes the practical solution which I use.
Chris' Guide to Safe International Data Transport
- Before going on any international trip, back up all of your important and potentially embarrassing, incriminating, or troubling data. This includes any copyrighted content which you may not be able to prove you own.
- Create an encrypted disk image/encrypted folder of that data. This can be done with Pretty Good Privacy, Truecrypt, or software built into many operating systems.
- Remember the password. This is very important, as if you forget it, you lose all your data.
- Upload the encrypted data to a reliable place on the Internet (or two). Personally, I use Amazon S3, which charges 15 cents per GB-month of storage plus 17 cents per GB of data transfer.
- Wipe your laptop clean (do this properly, or the data may be accessible after the fact with forensics software), and install a fresh copy of your OS onto it.
- Travel. You should have no problem at U.S. Customs (or in any other country) as you won't have anything problematic on your computer.
- At your hotel/office, fire up your Web browser and download the encrypted data file from Amazon's servers.
- Decrypt the data.
Once you are done with your trip, you can simply re-encrypt the data, upload it to Amazon again, and wipe the disk clean.
For those of you traveling to countries (or places in the U.S.) with slow Internet connections, you may wish to burn your encrypted data to a DVD and FedEx it to your destination. Do it a few days before you leave, and you should know before you get on the airplane if the disk made it to your destination safely by checking the delivery status online.
I realize that I take paranoia to a more extreme level than most, but I find that this technique works really, really well for me. For those of you who are even more paranoid, and are worried about customs agents being able to recover the deleted data from your laptop disk, you may wish to avoid keeping the decrypted data on your laptop at all (while on the trip). Portable flash drives are quite cheap these days, and can be easily destroyed (a microwave, a hammer, driving over them in a rental car, etc.) once your trip is done.
Disclosure: Jennifer Granick represented me, pro-bono, in my civil troubles with TSA back in 2006 and 2007.
Public interest groups, academics and members of the press have hammered Google for its lax privacy policies. The criticism has mostly focused on the log deletion practices and browser cookie policies at the search giant. Google claims that search quality and user privacy are a zero-sum game: deleting log data makes it more difficult to improve search results. Perhaps the company is right. However, there are several other pro-privacy steps that Google could take to significantly protect its customers--which it has not done, and continues to reject.
Over the last few months, a number of Google's engineers have issued public statements on the company's public policy blog to defend its much criticized log data retention policies. The company claims that the data can be used to hunt down malware, to catch people defrauding its advertising system, and can be used to improve search results.
These high-profile Googlers make the case that user privacy and search quality are a zero sum game: deleting logs to protect customer privacy makes it far more difficult to provide a good search experience.
While I personally think this is a load of rubbish, I'm going to give them the benefit of the doubt today, because I want to focus on a different issue. Namely, that Google could take a few easy steps in other areas to protect customers from the prying eyes of AT&T, the NSA, or the pervert next door reading your e-mails sent over a wireless network.
Search terms
Imagine a normal search situation. A user will visit Google.com, type in a few words, "security blogs," perhaps, and click on the search button. From the search results page, a user will click on a link, taking them to www.some-website.com. Due to the way that Google has designed its search engine, Web site owners are given the search terms that brought each Web surfer to their site.
A more technical explanation of this is as follows: Google embeds the search terms that the user issued into the Web URL of the search response page. That is, an example search URL will look like http://www.google.com/search?q=security+blogs . This is known as a HTTP GET request. When a user clicks on one of the search results on that page, the Web site owner will be told the exact address of the referring Web site. Due to the fact that Google embeds the search terms in its results URL, the Web site owner learns which terms lead a user to their page.
Google could very easily stop including the search terms in the URL and thus stop passing on the search terms to the Web sites that users click on from a Google results page. It could do so by requesting that the user's browser send the terms to a Google server in a more discrete way. Many Web sites do this, especially those dealing with private information. Amazon.com and other e-commerce sites do not transmit the customer's credit card information by sending it in the URL--even on a SSL-encrypted Web session. To do so would needlessly endanger the user.
A switch to this more privacy-protecting method of Web data submission, known as a HTTP POST, would be a trivial change for Google's engineers. Furthermore, it wouldn't lead to any additional data processing resources for its vast number of servers. For Google, such a change would cost the company essentially nothing yet it would give its customers an immediate increase in privacy.
The only downside to such a change, would be the loss of information for Web masters. Companies would like to know which search terms drew a customer to their Web site, especially if that visit resulted in a sale. While no doubt useful for marketers, this is not something they deserve to know. Furthermore, Google's responsibility is to the users with the eyeballs. At the very least, if a firm wants to know what people are searching for--let it buy an advertisement from Google. Right now, Google gives this data away to every Web site owner, for free.
Encrypted mail
By default, all Google searches as well as e-mail sent and read via Gmail are transmitted in the open, over an unencrypted session. What that means, is that the data can be seen by anyone with access to the network--anyone else using the Wi-Fi connection at Starbucks, your Internet service provider, or any government agency that has tapped the Internet backbone.
All Web browsers support the SSL encryption standard. Google even offers encrypted access to Gmail users, if they know to ask for it. Users simply need to visit https://www.gmail.com, and their e-mail entire session will be safe from prying eyes.
Unfortunately, encryption is expensive, at least in terms of computing power. Turning SSL on by default for the millions of Gmail users would mean that Google would have to dedicate more computers to the service. Those computers cost money. A Google spokesperson confirmed this, telling me that "we have not made SSL the default due to capacity and latency issues."
Google has made a shrewd business decision: Those users who care enough about their privacy to read the company's FAQ can get a bit of protection for their e-mail, while those users who presumably don't care, are left exposed to hackers and snoops.
Google should change its policies with regard to SSL and e-mail. At the very least, it should mention the secure Web mail option and provide a link on the main Gmail log-in page. This information is currently hidden in one of the help pages. In an ideal world, Gmail would enable SSL by default.
Searches, exposed.
While the company offers encrypted Web mail, it does not do the same for searches. Currently, there is no way to keep your search terms secret from those who might be watching the network. Could the company offer this? Sure, but it has chosen not to. Primarily, because of cost.
Luckily, someone else has taken steps to fill the search privacy gap left by Google.com. A Texas man named Daniel Brandt has created a Google-powered privacy-preserving search engine: Scroogle.org.
Scroogle submits search queries to Google on a user's behalf, scrapes the results, and displays them to the user. Scroogle's search data policies are fantastic: no cookies, no search-term records and all access logs are deleted within 48 hours. The site uses HTTP POST requests by default, which helps to keep the search terms a secret between the user and the search engine. Furthermore, for those users willing to put up with the 1- or 2-second delay required to initiate an SSL connection, encrypted searches are available to users via https://ssl.scroogle.org/.
Over 130,000 searches per day are made through the Scroogle site, 10 percent of which use SSL. In an e-mail conversation, Daniel told me that his "ultimate goal is for Scroogle to survive long enough so that the public sector gets the idea that all major search engines should be treated like public utilities."
Daniel Brandt seems like a great guy. He's doing this for free--and accepts tax deductible donations on the Scroogle site. However, for users who don't trust Daniel's claims, they may wish to use the anonymizing TOR proxy in parallel with Scroogle.
What Daniel's site shows, is that privacy preserving search is possible. While Scroogle doesn't show any ads, if Google offered this service, they could still make a buck on it. Imagine that--making money, while not being evil.
Disclosure: I'm paid as a technology policy fellow by the Electronic Privacy Information Center, a public interest group that has repeatedly criticized Google for its privacy policies. Furthermore, I interned for Google in 2006, and have received a $5,000 fellowship from the company, both in 2006 and 2007.
Gefen's HD video recorder still has HDMI inputs, but the recordings will now be encrypted.
(Credit: Gefen)Gefen is adding hard-drive encryption to its High-Definition Personal Video Recorder to ensure that it won't become an easy avenue for video piracy. Doing so will bring the product into line with other commercially available set-top recorders and DVRs, all of which encrypt video recordings to ensure they won't be played back outside of the device.
The addition of encryption follows a dialogue with CNET that was initiated after the Gefen HD PVR was highlighted on Zatznotfunny. Blogger Dave Zatz noted that the Gefen was a unique product: not only did it have HDMI inputs--a usually unseen rarity--its recordings were completely unencrypted. That meant that enterprising techies such as Zatz (and fellow enthusiast "AVeNVy") who were willing to crack open the Gefen and yank out the hard drive were able to view high-def recordings from their cable box as standard (albeit undoubtedly massive) H.264 video files when they connected the drive to a PC. Such unencrypted/non-DRM video files are the holy grail of video pirates, who could take those files and put them on file-sharing networks. Imagine, for instance, a whole month of high-def HBO movies as Pirate Bay torrents, and it's easy to see why Hollywood studios tend to demand tough encryption standards from hardware manufacturers.
When contacted for comment last week, Gefen specified that the device was "preserving HDCP [High-Definition Copy Protection] on output." But a subsequent communication from the company's representative has since clarified the issue:
Gefen did not anticipate that users would void warranty to crack the unit and use the internal drive in this fashion. The company is currently in the process of encrypting every internal drive of every HD PVR so this situation will be corrected.
The product is brand new, so it's unclear how many of the pre-encryption models are already in the wild. But if you see one of them on eBay going for more than the $1,000 list price, you'll know why.
Late last month, researchers at Princeton made headlines when they published a paper exposing weaknesses in PC encryption technologies. It seems that DRAMs retain resident data for several minutes after PCs are shut down. This vulnerability can lead to "cold boot attacks" that can expose any information stored in PC memory--including encryption keys. Using several different types of attacks, researchers were able to exploit this vulnerability to defeat several disk encryption systems including BitLocker (Microsoft Windows), FileVault (Apple Macintosh), and TrueCrypt (Open Source). Read more about this security research here. (PDF)
The Princeton report renewed a well-understood problem in the security community. Many encryption technologies are far more vulnerable than you think. That said, should chief information security officers be concerned? Yes and no.
When I first read this study, my initial reaction was that this was old news that was only relevant to the security research and academic communities. If my PC is stolen at Logan Airport or I leave it in a New York City cab, chances are pretty good that it gets fenced on the street for a few hundred bucks or traded for tubes of crack. In a situation like this, any Full-Disk Encryption (FDE) solution serves its purpose by providing anti-disclosure insurance. In other words, if my PC contains regulated data when it is stolen, FDE gives me a "get out of jail free" card on regulations like California SB 1386--I don't have to disclose this data breach to the public or suffer the associated embarrassment and cost.
Given this scenario, Joe Blow FDE software is sufficient most of the time, but security attacks are getting more targeted and sophisticated each day. Additionally, ESG Research data indicates that about one-third of large organizations (for example, 1,000 employees or more) suffered a data breach in the last 12 months and about half of these breaches were carried out by insiders. Given the right circumstances, a junior IT administrator could use a cold boot attack to steal valuable information from a C-level executive. Cold boot attacks also provide a new avenue for industrial espionage since many users leave laptops in hibernation mode when they travel.
Yes, there are ways to minimize the possibility of a cold boot attack against vulnerable encryption tools but security best practices state that if you are going to implement security technologies, you ought to choose those that provide the highest security possible. BitArmor, Intel (Danbury), and Seagate offer examples of encryption technologies immune to the Princeton attacks. My guess is that others will quickly follow.
With information security, never underestimate the bad guy's skills and desires. As Sun Tzu said in The Art of War, "If you know your enemy and know yourself, you need not fear the results of a hundred battles. If you know yourself but not your enemy, for every victory gained you will also suffer a defeat. If you know neither your enemy nor yourself, you will succumb in every battle."
A few weeks ago there were two interesting announcements involving encryption technologies. First, SafeNet acquired application and database encryption leader Ingrian while Symantec announced that it will partner with GuardianEdge to provide Full Disk Encryption (FDE) for PC security.
Why did SafeNet buy Ingrian rather than simply partner? Because SafeNet has made its mark selling security widgets not security solutions. This business model holds less appeal when large organizations fold security into their global governance, risk management, and compliance requirements. With Ingrian in hand, SafeNet can compete on these kind of enterprise deals and become a more strategic vendor to customers.
SafeNet-Ingrian is pretty straightforward, but why wouldn't Symantec simply buy GuardianEdge? Symantec certainly has the money and the industry precedent was set when Check Point purchased PC encryption vendor PointSec while McAfee grabbed SafeBoot.
Symantec looked at the market and saw a very short runway to make money. Hardware-based FDE is clearly on the horizon, led by Intel, Hitachi, and Seagate Technology. Pretty soon, laptops will ship with encryption already baked in, so the market for software solutions can be measured in the 12-to-24-month timeframe. With so little time to make an acquisition accretive, Symantec decided that partnering with an industry leader was a better business decision.
There are a lot of encryption and key management start-ups available and I expect a lot of acquisitions, partnerships, fire sales, and bankruptcies over the next few years. One way or another, users want to encrypt their confidential data sooner rather than later. Which vendors win and which lose is another story.
On Monday, Cryptography Research Inc. (CRI) opened a three-day workshop in San Francisco on the security of embedded system cryptography. The workshop is intended for developers and architects of secure embedded systems. Participants will be given smart cards and challenged to crack passwords using various demonstrated techniques.
"These are not theoretical attacks," Benjamin Jun, vice president of technology at CRI, noting that his company published the first white paper on monitoring attacks during the 1990s.
The workshop's primary focus will be on attacks to Elliptic Curve Cryptography (ECC), a cryptographic algorithm that is now used to protect electronic passports, mobile communications, and even MP3 players. Jun said there are many ways for an attacker to monitor leakage. In the workshop, he said they will look specifically at Simple Power Analysis (SPA) and Differential Power Analysis (DPA).
"Almost every smart card you buy today is going to have countermeasures to Simple Power Analysis and Differential Power Analysis," said Jun, however some newer implementations of ECC "do in fact leak information." In particular he cited devices such as MP3 players and cell phones. These are devices that have not had 10 years of development, said Jun, and so some exhibit weaknesses found in early smart cards. The purpose of the workshop was to help developers avoid some common flaws.
Under SPA, an attacker can determine the passwords from simple patterns in the power consumption.
(Credit: CRI)To an observer, a power analysis looks something like an EKG. As the device processes the encryption algorithm, peaks and valleys display on the monitor; these ultimately correspond to 1s and 0s in a password. Thus, an attacker could look at the power consumption fluctuations emitted from a device and, based on the specific pattern of peaks and valleys, figure out whether the device used RSA, DES, or ECC for encryption. Knowing what algorithm was used, the attacker could then begin to figure out the password.
Under DPA, the attacker first guesses and then compares the guess against the actual result.
(Credit: CRI)Counter measures, said Jun, include increasing the signal-to-noise ratio. For example, if you want to have a private conversation, you could go to a large football stadium during a game, making it hard for someone trying to listen to separate our conversation from the surrounding noise. That's amplitudinal noise.
The other kind of noise, said Jun, is temporal, which, to a computer, means stuttering the information over longer spaces. For example, if the data value was 8, the code might be expressed as 2 plus 6. More defense can be achieved by randomness, changing the way you express the data value of 8; maybe the next reference you say 12 minus 4, then 5 plus 3, and so on.
The workshop concludes Wednesday. For an overview of the concepts involved in a monitored attack, CRI provides a Flash tutorial on its Web site.
There was a relatively small acquisition on Tuesday: nCipher, a U.K.-based encryption specialist, purchased storage encryption appliance vendor NeoScale Systems. This could be looked at as basic industry consolidation, but the impact could ripple further.
Encryption and, more specifically, key management really needs a set of standards to prosper and grow. Key management standards must include standard ways to connect encrypting devices to key managers, key managers to key managers, and so on. There are a few nascent standards efforts in this area, but nothing concrete.
Here's how this niche merger could impact the stalemate. nCipher has strong relationships with IBM, while NeoScale works closely with EMC-RSA. nCipher also has developed some very simple yet elegant key management communications standards and interfaces. If nCipher-NeoScale can build some consensus on standards with IBM and EMC-RSA, the rest of the industry is bound to follow. This could lead to a pragmatic solution to a vexing problem.
The industry needs leadership here. If we don't fix the key management standards problem, data is bound to get lost or stolen while operating costs increase. If nCipher-NeoScale can help move the industry in the right direction, this seemingly minor merger could have a profound industry impact.
Malicious attackers are increasingly setting their sights on targeted phishing attacks, or "spear" phishing, and custom-built applications, pushing these two areas into Sans' Top 20 Internet Security Risks of 2007.
The report, released Tuesday, provides a glimpse into the nefarious activities of online attackers and the issues faced by security firms.
"Spear phishing has had its most critical and damaging impact in military and civilian government organizations and military contractors who build weapons and more," said Alan Paller, Sans Institute research director.
He estimated that 90 percent of the attacks that caused the greatest damage over the past 18 months targeted the military and government entities, as well as defense contractors. Corporate executives are also increasingly finding themselves as targets of spear phishing.
"It's done as an act of espionage, and not so much for economic gain," Paller said during a press conference with other security experts to release the report.
A chief information officer at a midsize federal agency, for example, discovered his own computer was sending out data to China, unbeknownst to him, according to a composite cited in the report.
And in an effort to tackle the the weakest security link in an organization, one federal agency has taken the unusual step of sending out a benign version of a phishing attack to its employees and further educating those who bite on security measures they should be taking.
Phishing is used for economic gain, as a means to lure users into giving up their log-on and passwords, as well as such sensitive information as Social Security numbers and bank accounts.
Custom-built applications have also gained favor with malicious attackers, due to developers' lackadaisical approach in designing security into the software. Previously, attackers used to concentrate their efforts on widespread software.
Other frequent attack targets cited on the list include Web browsers, Office software, e-mail clients and media players on the client side, while Windows services, Unix and Mac OS services and database software were listed on the server side of the equation.
Unencrypted laptops and removable media, as well as VoIP servers and phones, also made it on the list.
Requirement 3.4 in the Payment Card Industry Data Security Standard mandates that financial service and retail companies, "render Primary Account Number (PAN), at minimum, unreadable anywhere it is stored." While the PCI standard provides a number of ways to do this, most large companies equate the term "unreadable" with encryption.
So here is the rub. PAN data is stored in a bunch of places but everyone stores it in databases. I'm talking about massive databases here--think hundreds of gigabytes to terabytes of data in many cases. Now when your database gets this big, you become very sensitive to performance and latency. Applications and databases are finely tuned and business processes and reporting is based upon extremely high transaction rates. Time is literally money.
There is an absolute technology mismatch here. Encrypting database columns is often done with stored procedures and triggers. Between these database routines and cryptographic processing, you need two things, processing horsepower and time. With applications like credit card processing, these are in very short supply. Oh sure, you can add more memory and processors to a system, but these changes don't come for free and encryption throws a monkey wrench into system tuning and capacity planning.
Something has to give here. Operating systems and databases may have to provide encryption sub-routines delegated to specific cryptographic hardware shipped on every system. Encrypted columns may need to be stored on encrypted disk drives. My point is that the industry needs to look at problems like these collectively across the "IT stack" and not just on their individual domains. If you don't believe me, ask your customers.





