Encryption as Evidence of Criminal Intent
An appeals court in Minnesota has ruled that the presence of encryption software on a computer may be viewed as evidence of criminal intent.
I am speechless.
Edited to add: The complete text is online.
Entries Tagged "encryption"
Page 55 of 56
AES Timing Attack
Nice timing attack against AES.
For those of you who don’t know, timing attacks are an example of side-channel cryptanalysis: cryptanalysis using additional information about the inner workings of the cryptographic algorithm. I wrote about them here.
What’s the big idea here?
There are two ways to look at a cryptographic primitive: block cipher, digital signature function, whatever. The first is as a chunk of math. The second is a physical (or software) implementation of that math.
Traditionally, cryptanalysis has been directed solely against the math. Differential and linear cryptanalysis are good examples of this: high-powered mathematical tools that can be used to break different block ciphers.
On the other hand, timing attacks, power analysis, and fault analysis all makes assumptions about implementation, and uses additional information garnered from attacking those implementations. Failure analysis assumes a one-bit feedback from the implementation—was the message successfully decrypted—in order to break the underlying cryptographic primitive. Timing attacks assumes that an attacker knows how long a particular encryption operation takes.
RFID Passport Security
According to a Wired article, the State Department is reconsidering a security measure to protect privacy that it previously rejected.
The solution would require an RFID reader to provide a key or password before it could read data embedded on an RFID passport’s chip. It would also encrypt data as it’s transmitted from the chip to a reader so that no one could read the data if they intercepted it in transit.
The devil is in the details, but this is a great idea. It means that only readers that know a secret data string can query the RFID chip inside the passport. Of course, this is a systemwide global secret and will be in the hands of every country, but it’s still a great idea.
It’s nice to read that the State Department is taking privacy concerns seriously.
Frank Moss, deputy assistant secretary for passport services, told Wired News on Monday that the government was “taking a very serious look” at the privacy solution in light of the 2,400-plus comments the department received about the e-passport rule and concerns expressed last week in Seattle by
participants at the Computers, Freedom and Privacy conference. Moss said recent work on the passports conducted with the National Institute of Standards and Technology had also led him to rethink the issue.“Basically what changed my mind was a recognition that the read rates may have actually been able to be more than 10 centimeters, and also recognition that we had to do everything possible to protect the security of people,” Moss said.
The next step is for them to actually implement this countermeasure, and not just consider it. And the step after that is for us to get our hands on some test passports to see if they’ve implemented it well.
The Doghouse: ExeShield
Yes, there are companies that believe that keeping cryptographic algorithms secret makes them more secure.
ExeShield uses the latest advances in software protection and encryption technology, to give your applications even more protection. Of course, for your security and ours, we won’t divulge the encryption scheme to anyone.
If anyone reading this needs a refresher on exactly why secret cryptography algorithms are invariably snake oil, I wrote about it three years ago.
The Doghouse: Xavety
It’s been a long time since I doghoused any encryption products. CHADSEA (Chaotic Digital Signature, Encryption, and Authentication) isn’t as funny as some of the others, but it’s no less deserving.
Read their “Testing the Encryption Algorithm” section: “In order to test the reliability and statistical independency of the encryption, several different tests were performed, like signal-noise tests, the ENT test suite (Walker, 1998), and the NIST Statistical Test Suite (Ruhkin et al., 2001). These tests are quite comprehensive, so the description of these tests are subject of separate publications, which are also available on this website. Please, see the respective links.”
Yep. All they did to show that their algorithm was secure was a bunch of statistical tests. Snake oil for sure.
RFID Security Analysis
A very impressive analysis of the Texas Instruments RFID technology used in a variety of security systems, such as vehicle immobilizers and ExxonMobil’s SpeedPass system.
Mistake number 1: The cryptographic algorithm is a proprietary 40-bit cipher.
Flaw in Winkhaus Blue Chip Lock
The Winkhaus Blue Chip Lock is a very popular, and expensive, 128-bit encrypted door lock. When you insert a key, there is a 128-bit challenge/response exchange between the key and the lock, and when the key is authorized it will pull a small pin down through some sort of solenoid switch. This allows you to turn the lock.
Unfortunately, it has a major security flaw. If you put a strong magnet near the lock, you can also pull this pin down, without authorization—without damage or any evidence.
The worst part is that Winkhaus is in denial about the problem, and is hoping it will just go away by itself. They’ve known about the flaw for at least six months, and have done nothing. They haven’t told any of their customers. If you ask them, they’ll say things like “it takes a very special magnet.”
From what I’ve heard, the only version that does not have this problem is the model without a built-in battery. In this model, the part with the solenoid switch is aimed on the inside instead of the outside. The internal battery is a weak spot, since you need to lift a small lid to exchange it. So this side can never face the “outside” of the door, since anyone could remove the batteries. With an external power supply you do not have this problem, since one side of the lock is pure metal.
A video demonstration is available here.
Microsoft RC4 Flaw
One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext—and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.
It’s an amateur crypto mistake. The easy way to prevent this attack is to use a unique initialization vector (IV) in addition to the key whenever you encrypt a document.
Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. Hongjun Wu has details (link is a PDF).
In this report, we point out a serious security flaw in Microsoft Word and Excel. The stream cipher RC4 [9] with key length up to 128 bits is used in Microsoft Word and Excel to protect the documents. But when an encrypted document gets modified and saved, the initialization vector remains the same and thus the same keystream generated from RC4 is applied to encrypt the different versions of that document. The consequence is disastrous since a lot of information of the document could be recovered easily.
This isn’t new. Microsoft made the same mistake in 1999 with RC4 in WinNT Syskey. Five years later, Microsoft has the same flaw in other products.
Airline Passenger Profiling
From an anonymous reader who works for the airline industry in the United States:
There are two initiatives in the works, neither of which leaves me feeling very good about privacy rights.
The first is being put together by the TSA and is called the “Secure Flight Initiative.” An initial test of this program was performed recently and involved each airline listed in the document having to send in passenger information (aka PNR data) for every passenger that “completed a successful domestic trip” during June 2004. A sample of some of the fields that were required to be sent: name, address, phone (if available), itinerary, any comments in the PNR record made by airline personnel, credit card number and expiration date, and any changes made to the booking before the actual flight.
This test data was transmitted to the TSA via physical CD. The requirement was that we “encrypt” it using pkzip (or equivalent) before putting it on the CD. We were to then e-mail the password to the Secure Flight Initiative e-mail address. Although this is far from ideal, it is in fact a big step up. The original process was going to have people simply e-mail the above data to the TSA. They claim to have a secure facility where the data is stored.
As far as the TSA’s retention of the data, the only information we have been given is that as soon as the test phase is over, they will securely delete the data. We were given no choice but had to simply take their word for it.
Rollout of the Secure Flight initiative is scheduled for “next year” sometime. They’re going to start with larger carriers and work their way down to the smaller carriers. It hasn’t been formalized (as far as I know) yet as to what data will be required to be transmitted when. My suspicion is that upon flight takeoff, all PNR data for all passengers on board will be required to be sent. At this point, I still have not heard as to what method will be used for data transmission.
There is another initiative being implemented by the Customs and Border Protection, which is part of the Department of Homeland Security. This (unnamed) initiative is essentially the same thing as the Secure Flight program. That’s right—two government agencies are requiring us to transmit the information separately to each of them. So much for information sharing within the government.
Most larger carriers are complying with this directive by simply allowing the CBP access to their records directly within their
reservation systems (often hosted by folks like Sabre, Worldspan, Galileo, etc). Others (such as the airline I work for) are opting to
only transmit the bare requirements without giving direct access to our system. The data is transmitted over a proprietary data network that is used by the airline industry.There are a couple of differences between the Secure Flight program and the one being instituted by the CBP. The CBP’s program requires that PNR data for all booked passengers be transmitted:
- 72 hours before flight time
- 24 hours before flight time
- 8 hours before flight time
- and then again immediately after flight departure
The other major difference is that it looks as though there will be a requirement that we operate in a way that allows them to send a request for data for any flight at any time which we must send back in an automated fashion.
Oh, and just as a kick in the pants, the airlines are expected to pay the costs for all these data transmissions (to the tune of several thousand dollars a month).
Safe Personal Computing
I am regularly asked what average Internet users can do to ensure their security. My first answer is usually, “Nothing—you’re screwed.”
But that’s not true, and the reality is more complicated. You’re screwed if you do nothing to protect yourself, but there are many things you can do to increase your security on the Internet.
Two years ago, I published a list of PC security recommendations. The idea was to give home users concrete actions they could take to improve security. This is an update of that list: a dozen things you can do to improve your security.
General: Turn off the computer when you’re not using it, especially if you have an “always on” Internet connection.
Laptop security: Keep your laptop with you at all times when not at home; treat it as you would a wallet or purse. Regularly purge unneeded data files from your laptop. The same goes for PDAs. People tend to store more personal data—including passwords and PINs—on PDAs than they do on laptops.
Backups: Back up regularly. Back up to disk, tape or CD-ROM. There’s a lot you can’t defend against; a recent backup will at least let you recover from an attack. Store at least one set of backups off-site (a safe-deposit box is a good place) and at least one set on-site. Remember to destroy old backups. The best way to destroy CD-Rs is to microwave them on high for five seconds. You can also break them in half or run them through better shredders.
Operating systems: If possible, don’t use Microsoft Windows. Buy a Macintosh or use Linux. If you must use Windows, set up Automatic Update so that you automatically receive security patches. And delete the files “command.com” and “cmd.exe.”
Applications: Limit the number of applications on your machine. If you don’t need it, don’t install it. If you no longer need it, uninstall it. Look into one of the free office suites as an alternative to Microsoft Office. Regularly check for updates to the applications you use and install them. Keeping your applications patched is important, but don’t lose sleep over it.
Browsing: Don’t use Microsoft Internet Explorer, period. Limit use of cookies and applets to those few sites that provide services you need. Set your browser to regularly delete cookies. Don’t assume a Web site is what it claims to be, unless you’ve typed in the URL yourself. Make sure the address bar shows the exact address, not a near-miss.
Web sites: Secure Sockets Layer (SSL) encryption does not provide any assurance that the vendor is trustworthy or that its database of customer information is secure.
Think before you do business with a Web site. Limit the financial and personal data you send to Web sites—don’t give out information unless you see a value to you. If you don’t want to give out personal information, lie. Opt out of marketing notices. If the Web site gives you the option of not storing your information for later use, take it. Use a credit card for online purchases, not a debit card.
Passwords: You can’t memorize good enough passwords any more, so don’t bother. For high-security Web sites such as banks, create long random passwords and write them down. Guard them as you would your cash: i.e., store them in your wallet, etc.
Never reuse a password for something you care about. (It’s fine to have a single password for low-security sites, such as for newspaper archive access.) Assume that all PINs can be easily broken and plan accordingly.
Never type a password you care about, such as for a bank account, into a non-SSL encrypted page. If your bank makes it possible to do that, complain to them. When they tell you that it is OK, don’t believe them; they’re wrong.
E-mail : Turn off HTML e-mail. Don’t automatically assume that any e-mail is from the “From” address.
Delete spam without reading it. Don’t open messages with file attachments, unless you know what they contain; immediately delete them. Don’t open cartoons, videos and similar “good for a laugh” files forwarded by your well-meaning friends; again, immediately delete them.
Never click links in e-mail unless you’re sure about the e-mail; copy and paste the link into your browser instead. Don’t use Outlook or Outlook Express. If you must use Microsoft Office, enable macro virus protection; in Office 2000, turn the security level to “high” and don’t trust any received files unless you have to. If you’re using Windows, turn off the “hide file extensions for known file types” option; it lets Trojan horses masquerade as other types of files. Uninstall the Windows Scripting Host if you can get along without it. If you can’t, at least change your file associations, so that script files aren’t automatically sent to the Scripting Host if you double-click them.
Antivirus and anti-spyware software : Use it—either a combined program or two separate programs. Download and install the updates, at least weekly and whenever you read about a new virus in the news. Some antivirus products automatically check for updates. Enable that feature and set it to “daily.”
Firewall : Spend $50 for a Network Address Translator firewall device; it’s likely to be good enough in default mode. On your laptop, use personal firewall software. If you can, hide your IP address. There’s no reason to allow any incoming connections from anybody.
Encryption: Install an e-mail and file encryptor (like PGP). Encrypting all your e-mail or your entire hard drive is unrealistic, but some mail is too sensitive to send in the clear. Similarly, some files on your hard drive are too sensitive to leave unencrypted.
None of the measures I’ve described are foolproof. If the secret police wants to target your data or your communications, no countermeasure on this list will stop them. But these precautions are all good network-hygiene measures, and they’ll make you a more difficult target than the computer next door. And even if you only follow a few basic measures, you’re unlikely to have any problems.
I’m stuck using Microsoft Windows and Office, but I use Opera for Web browsing and Eudora for e-mail. I use Windows Update to automatically get patches and install other patches when I hear about them. My antivirus software updates itself regularly. I keep my computer relatively clean and delete applications that I don’t need. I’m diligent about backing up my data and about storing data files that are no longer needed offline.
I’m suspicious to the point of near-paranoia about e-mail attachments and Web sites. I delete cookies and spyware. I watch URLs to make sure I know where I am, and I don’t trust unsolicited e-mails. I don’t care about low-security passwords, but try to have good passwords for accounts that involve money. I still don’t do Internet banking. I have my firewall set to deny all incoming connections. And I turn my computer off when I’m not using it.
That’s basically it. Really, it’s not that hard. The hardest part is developing an intuition about e-mail and Web sites. But that just takes experience.
This essay previously appeared on CNet
Sidebar photo of Bruce Schneier by Joe MacInnis.