Tuesday, November 24, 2009
Encryption and key demands, in reality
Two years ago I posted an article that has been fairly popular, Encryption and Key Demands. The phrase 'duress key' seems to drive the traffic there, even though I'm not the one who coined the term. Anyway, a real-life example of that has shown up.
http://www.theregister.co.uk/2009/11/24/ripa_jfl/
UK jails schizophrenic for refusal to decrypt files
You don't fork over your decryption keys on demand, you get jail time just for that! As I said two years ago, this is a lot harder to pull off in the US due to that whole Bill of Rights thing. Harder, but not impossible.
Wednesday, August 12, 2009
Legal key recovery
Remember this? About the UK's new laws stating that failing to reveal decryption codes on-demand could result in jail sentences?
Well, it happened. We have yet to see what size of rubber hose is being used, but these two are being sized up.
Well, it happened. We have yet to see what size of rubber hose is being used, but these two are being sized up.
Monday, February 02, 2009
XKCD gets it (unsurprisingly)
Today's XKCD:
As one crypto-wonk I spoke to...um...10 years ago said, this is called, "rubber hose cryptanalysis". Or put another way, the easiest way to crack crypto is to attack the ends points. Don't waste your time brute-forcing the cypher text, kidnap the person who owns the password and beat them until they tell you what it is. Or grab the cleartext using a screen-scraper when the recipient decrypts it. Or sniff the crypto-password with a key-logger when it is enciphered. Or live-clone the box once the encrypted partition is mounted. Except for the beatings, US law enforcement has used all of these methods to circumvent encryption.
It is for this reason why the UK has passed a law making it an illegal activity to withhold crypto-passwords when demanded by law enforcement. Failure to reveal the passphrase will result in jail time, even if the crime they're investigating has a lower mandatory sentence. The cryptonerds that xkcd was lampooning have thought of this, which is where the concept of the duress key comes from; a key you give when you are under duress that when used will either destroy your data instead of revealing it or reveal an equivalent amount of innocent data.
The problem with a duress key like this is that law enforcement NEVER works on the live data if they can at all get away with it. Working on live data taints evidence-chains, which makes convictions harder. So you set up a duress key for your TruCrypt partition, UK police nab it, demand the password, you give the duress password, it'll only scrub the copy of the data they were working on. Now they know you lied to them, and you are now guaranteed to be asked firmly for the real password, if not thrown into jail for hampering a police investigation.
As one crypto-wonk I spoke to...um...10 years ago said, this is called, "rubber hose cryptanalysis". Or put another way, the easiest way to crack crypto is to attack the ends points. Don't waste your time brute-forcing the cypher text, kidnap the person who owns the password and beat them until they tell you what it is. Or grab the cleartext using a screen-scraper when the recipient decrypts it. Or sniff the crypto-password with a key-logger when it is enciphered. Or live-clone the box once the encrypted partition is mounted. Except for the beatings, US law enforcement has used all of these methods to circumvent encryption.
It is for this reason why the UK has passed a law making it an illegal activity to withhold crypto-passwords when demanded by law enforcement. Failure to reveal the passphrase will result in jail time, even if the crime they're investigating has a lower mandatory sentence. The cryptonerds that xkcd was lampooning have thought of this, which is where the concept of the duress key comes from; a key you give when you are under duress that when used will either destroy your data instead of revealing it or reveal an equivalent amount of innocent data.
The problem with a duress key like this is that law enforcement NEVER works on the live data if they can at all get away with it. Working on live data taints evidence-chains, which makes convictions harder. So you set up a duress key for your TruCrypt partition, UK police nab it, demand the password, you give the duress password, it'll only scrub the copy of the data they were working on. Now they know you lied to them, and you are now guaranteed to be asked firmly for the real password, if not thrown into jail for hampering a police investigation.
Labels: crypto
Monday, August 18, 2008
Enabling autokey auth in NTP on SLES10
The NTP protocol permits the use of crypto to authenticate clients and servers to each other, as well as between time servers. By default, SLES10 is set up to allow the v3 method of using symmetric keys, but not the v4 method that uses public/private keys. If you want to use the v4 method, this is the tip for you.
Background
Additionally, ntp runs with an AppArmor profile loaded against it for added security.
Getting NTPv4 auth to work
There are 4 steps to get this to work.
- Copy the .rnd file to the chroot jail
- Run ntp-keygen
- Modify the AppArmor profile for /usr/sbin/ntpd to allow read access to the new files
- Modify the /etc/ntp.conf file to enable v4 auth.
Copy the .rnd file to the chroot jail
timehost:~ # openssl rand -out /var/lib/ntp/etc/.rnd 1
Run ntp-keygen
Change-directory to /var/lib/ntp/etc, and execute the following command:
timehost:~ # ntp-keygen -T
Modify the AppArmor profile
- Launch YaST
- Go to the "Novell AppArmor" section, and enter the "Edit Profile" tool.
- Select "/usr/sbin/ntpd" and click Next.
- Click the "Add Entry" button and select File.
- Browse to /var/lib/ntp/etc/.rnd and click the "Read" permissions check-box, and click OK
- Repeat the previous two steps to add the two files created by ntp-keygen, named "ntpkey_cert_[hostname]" and "ntpkey_host_[hostname]".
- Note: AppArmor behavior changes between SP1 and SP2. In SP1 you can use the link files, in SP2 you need to specify the link targets.
- Click Done on the main Profile Dialog
- Agree to reload the AppArmor profile
Modify /etc/ntp.conf
keysdir /var/lib/ntp/etc/
crypto randfile /var/lib/ntp/etc/.rnd
Labels: coolsolutions, crypto, linux, sles, sysadmin
Thursday, December 27, 2007
eDirectory certificate server changes
The new eDir 8.8 has introduced some changes into my environment, and from the looks of it some of them were there before I did the upgrade. Specifically to the CA in the tree. In googling around, I found this excerpt from the CA documentation:
With Certificate Server 3.2 and later, in order to completely backup the Certificate Authority, it is necessary to back up the CRL database and the Issued Certificates database. On NetWare, these files are located in the sys:system\certserv directory.
For other platforms, both of these databases are located in the same directory as the eDirectory dib files. The defaults for these locations are as follows:
Windows: c:\novell\nds\dibfiles
Linux/AIX/Solaris: /var/opt/novell/edirectory/data/dib
These defaults can be changed at the time that eDirectory is installed.
The files to back up for the CRL database are crl.db, crl.lck, crl.01 and the crl.rfl directory. The files to back up for the Issue Certificates database are cert.db, cert.lck, cert.01, and the cert.rfl directory.
I didn't know about that directory. I also didn't know that the CA is publishing a certificate-revocation-list to sys:apache2\htdocs\crl\. Time to twiddle the backup jobs.
Thursday, November 15, 2007
Encryption & key demands
As some of you know, the UK has passed a law which authorizes jail time for people who refuse to turn over encryption keys. If I'm remembering right, 2-3 years. This is a bill that's been making the rounds for quite some time, and got passage as a terror bill. Nefarious elements have figured out that modern encryption technologies really can flummox even the US National Security Agency deep crack mainframes and they therefore use it. There was a reason that encryption technologies were classified a munition and therefore export-restricted.
Those of you who've been with Novell/NetWare long enough remember this. Back in the day the NICI and other PKI components came in three flavors, Domestic (strong, 128bit), International (weak, 40bit? 56bit?), and basic (none). Things have loosened up since then.
Part of the problem of encryption is that while the private keys may be strong, securing them is tricky. When the feds raid your house and grab every device capable of both digital computation and communication to throw into the evidence locker, their computer forensics people can get your private keys. However, if your private keys are further locked away, such as PGP, it won't do them much good. To gain access to your key-ring they'll need the pass-phrase.
That's where the new law in the UK comes in. Police have two options to figure out your pass-phrase. They can intercept it somehow, or they can point a jail term at your head and demand the the pass-phrase.
That doesn't work in the US thanks to the Bill of Rights, and the 5th Amendment. This is the amendment that states that you have a right to not self incriminate, and by extension this means that police can't force you to divulge information that could be detrimental to you. As it happens, the people who wrote this amendment had the English legal system in mind when they came up with the idea, what with us being an ex-colony and all that. So if you performed safe encryption handling, didn't write the pass phrase anywhere and made a point of making sure it never hit disk in the clear, the US Government can't penalize you for not telling them the pass phrase. A US law similar to the UK law would face a much harder judicial battle than it got in the UK.
Which isn't the case in the UK. As one crypto expert I spoke with once said, the UK law amounts to, "rubber-hose cryptography." Which is an allusion to the fact that a sufficient application of pain (i.e. torture) can cause someone to fork over their own encryption keys, which is a concern in certain totalitarian regimes.
The accepted response to 'rubber-hose' crypto methods is to use a 'duress key'. This key will either destroy the crypted data, or reveal harmless data (40GB of soft porn!). The problem with such a key is that it works best if such a key is not known to exist. Forensics analysis can show what kind of crypto is in use, and if that particular type supports the use of a duress key, the interrogators can work that into their own information extraction methods. Also, any forensics person worth their salt works on a COPY of the data (as the RIAA knows all too freaking well, digital data is very easy to duplicate), so having the duress key destroy the data isn't a loss. In a judicial framework, having the key given destroy the (copy of the) data can earn the person a, "hampering a lawful investigation," charge and even more jail time.
All that said and done, there are still PLENTY of ways for the US Government to gain access to pass-phrases. I've heard of at least one case where a key-logger was installed on a machine for the express purpose of intercepting the key-strokes of the pass-phrase. If the pass phrase exists in the physical realm in any way (outside of your head), they can execute search warrants on it. Some crypto programs don't handle pass-phrase handling well. Also, if you have a Word document that was crypted, then decrypted so you could view it, the temp files Word saves ever 5-10 minutes are in-the-clear and recoverable through sufficient disk analysis. The end-user needs to know about safe handling of in-the-clear data.
All of which is expensive work. If the Government can save several thousand dollars in tech time by simply asking you the pass phrase and throwing you in the clink if you don't give it, that's what they'll do. If the person under investigation is known to be very crypto savvy (uses a Linix machine, with an encrypted file-system that requires a hand-entered password to even load, and uses PGP or similar on top of that to defend against attacks when the file-system is mounted) it becomes WAY cheaper to go the Judicial route than the tech route.
Yeah, 2-3 years may be much better than the 20-life you'd face on a terrorism charge. But you'd be in custody the whole time, and they'll be spending that 2-3 years going over your encrypted data the hard way. And if actual actionable evidence surfaces to support a terrorism charge, you can bet your bippy that you'd be hauled into a court-house for a new trial, only this time facing 20-life. If you're in the UK. Here in the US they'll just keep you under surveillance until they get the pass phrase or enough other evidence to hold you down in custody and give them an excuse to throw everything you've ever touched into evidence lock-up.
Those of you who've been with Novell/NetWare long enough remember this. Back in the day the NICI and other PKI components came in three flavors, Domestic (strong, 128bit), International (weak, 40bit? 56bit?), and basic (none). Things have loosened up since then.
Part of the problem of encryption is that while the private keys may be strong, securing them is tricky. When the feds raid your house and grab every device capable of both digital computation and communication to throw into the evidence locker, their computer forensics people can get your private keys. However, if your private keys are further locked away, such as PGP, it won't do them much good. To gain access to your key-ring they'll need the pass-phrase.
That's where the new law in the UK comes in. Police have two options to figure out your pass-phrase. They can intercept it somehow, or they can point a jail term at your head and demand the the pass-phrase.
That doesn't work in the US thanks to the Bill of Rights, and the 5th Amendment. This is the amendment that states that you have a right to not self incriminate, and by extension this means that police can't force you to divulge information that could be detrimental to you. As it happens, the people who wrote this amendment had the English legal system in mind when they came up with the idea, what with us being an ex-colony and all that. So if you performed safe encryption handling, didn't write the pass phrase anywhere and made a point of making sure it never hit disk in the clear, the US Government can't penalize you for not telling them the pass phrase. A US law similar to the UK law would face a much harder judicial battle than it got in the UK.
Which isn't the case in the UK. As one crypto expert I spoke with once said, the UK law amounts to, "rubber-hose cryptography." Which is an allusion to the fact that a sufficient application of pain (i.e. torture) can cause someone to fork over their own encryption keys, which is a concern in certain totalitarian regimes.
The accepted response to 'rubber-hose' crypto methods is to use a 'duress key'. This key will either destroy the crypted data, or reveal harmless data (40GB of soft porn!). The problem with such a key is that it works best if such a key is not known to exist. Forensics analysis can show what kind of crypto is in use, and if that particular type supports the use of a duress key, the interrogators can work that into their own information extraction methods. Also, any forensics person worth their salt works on a COPY of the data (as the RIAA knows all too freaking well, digital data is very easy to duplicate), so having the duress key destroy the data isn't a loss. In a judicial framework, having the key given destroy the (copy of the) data can earn the person a, "hampering a lawful investigation," charge and even more jail time.
All that said and done, there are still PLENTY of ways for the US Government to gain access to pass-phrases. I've heard of at least one case where a key-logger was installed on a machine for the express purpose of intercepting the key-strokes of the pass-phrase. If the pass phrase exists in the physical realm in any way (outside of your head), they can execute search warrants on it. Some crypto programs don't handle pass-phrase handling well. Also, if you have a Word document that was crypted, then decrypted so you could view it, the temp files Word saves ever 5-10 minutes are in-the-clear and recoverable through sufficient disk analysis. The end-user needs to know about safe handling of in-the-clear data.
All of which is expensive work. If the Government can save several thousand dollars in tech time by simply asking you the pass phrase and throwing you in the clink if you don't give it, that's what they'll do. If the person under investigation is known to be very crypto savvy (uses a Linix machine, with an encrypted file-system that requires a hand-entered password to even load, and uses PGP or similar on top of that to defend against attacks when the file-system is mounted) it becomes WAY cheaper to go the Judicial route than the tech route.
Yeah, 2-3 years may be much better than the 20-life you'd face on a terrorism charge. But you'd be in custody the whole time, and they'll be spending that 2-3 years going over your encrypted data the hard way. And if actual actionable evidence surfaces to support a terrorism charge, you can bet your bippy that you'd be hauled into a court-house for a new trial, only this time facing 20-life. If you're in the UK. Here in the US they'll just keep you under surveillance until they get the pass phrase or enough other evidence to hold you down in custody and give them an excuse to throw everything you've ever touched into evidence lock-up.
Tuesday, October 02, 2007
The weakness of crypto
From Slashdot.
It is now legal in the UK for the government to force you to hand over your crypto keys, or face obstruction of justice charges.
This is what's known as, "rubber hose cryptography." Or, beating the holder of the crypto keys with a rubber hose until they relent and let you have them.
Banks are understandably wary of this law, as are privacy advocates. Failure to decrypt data on demand by the government will earn you jail-time, regardless of what offenses they may be planning to charge you with. If you refuse to decrypt, you'll STILL do time.
It is now legal in the UK for the government to force you to hand over your crypto keys, or face obstruction of justice charges.
This is what's known as, "rubber hose cryptography." Or, beating the holder of the crypto keys with a rubber hose until they relent and let you have them.
Banks are understandably wary of this law, as are privacy advocates. Failure to decrypt data on demand by the government will earn you jail-time, regardless of what offenses they may be planning to charge you with. If you refuse to decrypt, you'll STILL do time.
Labels: crypto
Monday, September 17, 2007
Email encryption
The last time I seriously took a look at email encryption was at my old job, using GroupWise 5.5. I did some poking around here with Exchange/Outlook and made it work, but it wasn't a serious look. Back then there was still real doubt about which standard would reign supreme: PGP (or GPG) vs S/MIME. PGP had been around for ages, where S/MIME used the same PKI infrastructure used by banks for secure online banking.
Outlook and GroupWise both had S/MIME built in. Both used the Microsoft crypto API. Remember, this was GW 5.5 so there was no Linux version yet.
If you look at posts on Bugtraq, clearly PGP is reigning supreme. A lot of posts there tend to be signed, and almost all of the signatures are GPG (the GnuPGP) or PGP. So that would tend to suggest that PGP-style stuff is winning. Except... bugtraq is primarily a Linux list that also bashes Microsoft, so the preference for the old school secure email (PGP) is easy to understand.
Yet why are the major email systems shipping with S/MIME built in?
There are several reasons why digitally signed email hasn't caught on. First and foremost it requires active use on the part of the user, in the form of explicitly stating "I trust this user and their certificate". Second, managing certificate renewals and changes adds work. Third, certificates for S/MIME are subject to the same SSL problems web-site certificates are, price. Fourth, the certificates (be it PGP or S/MIME) generally are only usable on a single operating system instance, which makes portability challenging.
Thawte.com still offers free email SSL certificates for personal use. I haven't read the details, but I suspect that 'professional use' is invalidated, which would prevent WWU from going to them whole-sale. I'll have to look.
The very nature of secure email makes it something only people who want it will strive for. This is not something that can be pushed down from On High unto the masses for enterprise deployment. Like sites with bad SSL certificates, Outlook will throw a Warning! message when it receives an email signed by a certificate it doesn't trust or know about. End users are notorious for being annoyed by pop-ups they view as superfluous. As with SSL certificates we have the Trusted Certificate Authority problem, which means that any external signed communication needs to be signed with a certificate already known by everyone (i.e. VeriSign, or similar).
And ALL of this doesn't look at the problem of digitally signed email in web clients like gmail. I have many friends who use their web browser as their primary email interface. AJAX can do a lot, but I don't know if it can do secure decryption/validation of email. I'm pretty sure AJAX can do insecure decryption/validation, which sort of violates the point. Right now, in order to do actual secure email you have to use a full mail client with support for the relevant protocol(s). Which means that, as above, only people serious about email security will take the steps to do email securely; it can't be mandated and invisible to the user.
So, things haven't changed much in the 4-5 years since I last looked at it.
Portability could be solved through creative use of a directory-service. I know for sure that eDir can store SSL certificates just peachy, the trick is getting them out and integrated into a mail client by way of LDAP. Active Directory has similar capabilities, but even Microsoft hasn't implemented AD/SMIME integration.
That said, directory integration provides its own problems. I, with my god like powers, can create and export private keys for generic users and through that securely impersonate them. This creates a non-repudiation problem, and is the reason that Microsoft's SecureAPI has a setting to require a password to be entered before using a certificate for signing. That password is currently set on the local machine, not in AD, which is how god-like-me can be foiled in my quest to forge emails.
Still, email security remains the purview of those to whom it is important. Lawyers and security professionals are the groups I run into most often that use it. I know some hobbyists that use the technology between themselves, but that's all it is, a way to prove that they can make the technology work in the first place. It still isn't ready for "the masses".
Outlook and GroupWise both had S/MIME built in. Both used the Microsoft crypto API. Remember, this was GW 5.5 so there was no Linux version yet.
If you look at posts on Bugtraq, clearly PGP is reigning supreme. A lot of posts there tend to be signed, and almost all of the signatures are GPG (the GnuPGP) or PGP. So that would tend to suggest that PGP-style stuff is winning. Except... bugtraq is primarily a Linux list that also bashes Microsoft, so the preference for the old school secure email (PGP) is easy to understand.
Yet why are the major email systems shipping with S/MIME built in?
There are several reasons why digitally signed email hasn't caught on. First and foremost it requires active use on the part of the user, in the form of explicitly stating "I trust this user and their certificate". Second, managing certificate renewals and changes adds work. Third, certificates for S/MIME are subject to the same SSL problems web-site certificates are, price. Fourth, the certificates (be it PGP or S/MIME) generally are only usable on a single operating system instance, which makes portability challenging.
Thawte.com still offers free email SSL certificates for personal use. I haven't read the details, but I suspect that 'professional use' is invalidated, which would prevent WWU from going to them whole-sale. I'll have to look.
The very nature of secure email makes it something only people who want it will strive for. This is not something that can be pushed down from On High unto the masses for enterprise deployment. Like sites with bad SSL certificates, Outlook will throw a Warning! message when it receives an email signed by a certificate it doesn't trust or know about. End users are notorious for being annoyed by pop-ups they view as superfluous. As with SSL certificates we have the Trusted Certificate Authority problem, which means that any external signed communication needs to be signed with a certificate already known by everyone (i.e. VeriSign, or similar).
And ALL of this doesn't look at the problem of digitally signed email in web clients like gmail. I have many friends who use their web browser as their primary email interface. AJAX can do a lot, but I don't know if it can do secure decryption/validation of email. I'm pretty sure AJAX can do insecure decryption/validation, which sort of violates the point. Right now, in order to do actual secure email you have to use a full mail client with support for the relevant protocol(s). Which means that, as above, only people serious about email security will take the steps to do email securely; it can't be mandated and invisible to the user.
So, things haven't changed much in the 4-5 years since I last looked at it.
Portability could be solved through creative use of a directory-service. I know for sure that eDir can store SSL certificates just peachy, the trick is getting them out and integrated into a mail client by way of LDAP. Active Directory has similar capabilities, but even Microsoft hasn't implemented AD/SMIME integration.
That said, directory integration provides its own problems. I, with my god like powers, can create and export private keys for generic users and through that securely impersonate them. This creates a non-repudiation problem, and is the reason that Microsoft's SecureAPI has a setting to require a password to be entered before using a certificate for signing. That password is currently set on the local machine, not in AD, which is how god-like-me can be foiled in my quest to forge emails.
Still, email security remains the purview of those to whom it is important. Lawyers and security professionals are the groups I run into most often that use it. I know some hobbyists that use the technology between themselves, but that's all it is, a way to prove that they can make the technology work in the first place. It still isn't ready for "the masses".
