Information Security

You are currently browsing the archive for the Information Security category.

Environment Controls Are Important to Security

March 5, 2010 in Hacking, Information Security | No comments

Well, we all knew they were, really… Computer and Information Security after all does (amongst other things) encompass availability and integrity, which can both be impacted by poor environment controls in the data-centre. There’s a popular adage that states that once a person has physical access, all bets are off, but all bets could be off if temperature is above operational parameters, or dirty power is introducing short-duration transient faults. New research has demonstrated a proof-of-concept attack against OpenSSL, and unlike side-channel attacks such as differential power analysis, the effect of these short-duration transient faults upon cryptographic signatures can be sampled without physical access to the device, assuming the signatures are sent via a network session.

The proof-of-concept involved induced short-duration transient faults, which resulted in recovery of private key bits. The remaining phase-space was explored on an eighty-one node cluster, and yielded a 1024-bit RSA key in approximately one-hundred hours. So far, this is difficult to induce, but the researchers state “If environmental conditions (such as high temperatures or voltage manipulation by an attacker) slow down the signal propagation in the system, it is possible that signals through the critical path do not reach their corresponding registers or latches before the next clock cycle begins.” (Pellegrini, A., Bertacco, V. & Austin, T. 2010)

Pellegrini, A., Bertacco, V. & Austin, T. (2010) ‘Fault-Based Attack of RSA Authentication’, University of Michigan [Online]. Available from: http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf (Accessed 5th March 2010).

Publishing Public Keys to Key-Servers Could Earn You Jail-Time

November 29, 2009 in Information Security | No comments

I was recently considering the news that the first incareration under Part III of the Regulation of Investigatory Powers Act (RIPA) had occurred. Yes, in case you haven’t heard, or are from the U.S. In the U.K. we do not have a right to refuse to provide potentially self-incriminating evidence. Under RIPA decryption keys can be demanded by the Police in any criminal investigation, refusal can lead to punitive incarceration of up to two years alleged crime other than anything related to terrorism, which would result in up to five years in jail. An unusual law that only seems to encourage rubber-hose crytoanalysis by the Police Service, in this example police officers allegedly said,

“There could be child pornography, there could be bomb-making recipes,” said one detective. “Unless you tell us we’re never gonna know… What is anybody gonna think?”

Clearly an attempt to coerce the suspect into releasing decryption keys. In this case the key was relating to Hard Disk Drives ETC., but it also seems to be a law that could be applied to content encryption mechanisms, such as PGP or GnuPG.

Now this is where things start to get a little sticky. HDD encryption is self-contained, in that unlike typical E-Mail or Voice encryption, we are not sharing a portion of the key material with anyone else, it’s limited by a physical boundary. Yet with E-Mail encryption this boundary does not exist, because it needs to work over a public network.

A sender will need to encrypt a message meant for a recipient with their public key, in order for the recipient (and hopefully only the recipient) to be able to decrypt the message with their private key. So in order to facilitate confidentiality, integrity and authenticity most users of PGP / GnuPG will make their public-keys available, on web-sites, on Facebook, or on key-servers… Can you see where this is leading? I wonder, how easy it would be for some nefarious sort to target a specific recipient with an e-mail encrypted with their public key (so only the private key can be used to decrypt it) implicating them in a crime via the subject heading, as the subject is not typically encrypted, and carbon-copying the nearest Police Service.

Better still, if such a person is going to do this, why would they not get more return for their time by searching the various key servers for all submitted keys for those in the United Kingdom, and then send a variation of the e-mail to them, carbon-copying the Police Service again. I wonder how many people would submit to relinquishing their keys in this case, compared to those that had either lost the keys, or refused to relinquish the keys. As Bruce Schneier states:

But if you’re guilty of something that can only be proved by the decrypted data, you might be better off refusing to divulge the key (and facing the maximum five-year penalty the statue provides) instead of being convicted for whatever more serious charge you’re actually guilty of.

There is of course the issue that assurance of identity is not provided through this form of e-mail encryption, so so one could simply register keys in other peoples names, and then perform the attack against them. This implies that they have the corresponding private key, which — of course — they don’t, because it’s probably the first they’ve heard of e-mail encryption. This could also be seen as a refusal to relinquish decryption keys. A similar demonstration / protest was made when the law was originally being bandied about.

The Over-Burdoning of Security Advice

November 24, 2009 in Information Security | No comments

Now that my academic modules are drawing to a close, I’ll be able to devote a little more time to the blog before I start the … dan-dan-dannn… Dissertation! So, a tip o’ the hat to Bruce Schneier for this paper from Cormac Herley on the rational rejection of security advice by a user population.

To make this concrete, consider an exploit that affects 1% of users annually, and they waste 10 hours clearing up when they become victims. Any security advice should place a daily burden of no more than 10/(365 × 100) hours or 0.98 seconds per user in order to reduce rather than increase the amount of user time consumed. This generates the profound irony that much security advice, not only does more harm than good (and hence is rejected), but does more harm than the attacks it seeks to prevent, and fails to do so only because users ignore it. In the model we set forward it is not users who need to be better educated on the risks of various attacks (as Adams et al. [21] suggest), but the security community. Security advice simply offers a bad cost-benefit tradeoff to users.

I just can’t fault logic such as this, and I’m sure we’ve all noted how confusing security awareness has become over the years for users. As Security professionals, we all read the advice that gets communicated to them through various channels, and we may find it pointless and lacking. Serving only to confuse the user or entirely fail to engage them in the first instance… Or worse, be utterly incorrect or at least fail to be applicable. Try as we might, we should eventually realise that users are not good at detecting fraud, nor are they good at doing our jobs for us!

Does this mean all security advice is useless? No, just a vast majority of it. In my opinion, an awareness programme should be cohesive and bespoke for each user population, for each organization to meet the top issues for that organization. It’s also important controls are in place to reduces the requirement for the secondment of users’ time to the security team. The awareness programme should be short, entertaining and designed to get users thinking about transferable security checks and balances, which they can then apply to their own processes.

Environment Creep in Printing

August 17, 2009 in Information Security | No comments

Back in the old days, printers were so damn expensive that many companies would have a print-room, dedicated to housing a single, or a couple of devices, fax machines, copiers, ETC. Now that these functions are typically rolled into a single and less expensive device, the printers are rolled out to the office space for multiple reasons, mostly because it’s convenient for the users, and dedicated print rooms are expensive considering how big they’d have to be to handle the increased demand (due to decreased price) for hard-copy materials.

Printers, or multi-functional devices sitting in general access office space can be a significant attack vector for anyone wishing to harvest some data. Due to the increased demand in usage, just about all office printers have a local hard disk drive to free up spooling resources at the server. However, spooling is done at the server because it’s assumed to be in a physically secure area, now with printers performing additional spooling on non-volatile media, the data sent for printing is no longer protected by enhanced physical security that comes with a dedicated data-center or communication’s room. Leaving physical access open to general employees and third-party contractors.

At this point, one should consider whether certain departments should participate in such schemes, or have their own dedicated printing facilities in a physically secure location. One should consider hard disk drive encryption to counter any casual, opportunist, or uninformed attack… Perhaps in certain environments we start implementing tamper-resistant hardware along the lines of ATMs, for example; pitting memory modules to mitigate against cold-boot attacks.

Facebook Connect Gone! OpenID In!

June 7, 2009 in Information Security, Site News | No comments

After much to’ing and fro’ing over the various Facebook Connect plugins, I decided to sit down and just think about what I was attempting to achieve. It became clear that Facebook should not be attempting to provide an identification service, they should just be holding content… If anything, they should be allowing third party identification services for users login on to Facebook. So I’ve opted to support OpenID for both this blog, and the forums.

City of Ely College… FAIL!

March 6, 2009 in Hacking, Information Security | No comments

City of Ely Community College has recently implemented a biometric registration system for its sixth formers. It uses face recognition techniques combined with a four digit PIN in order to check students in, and out again. Great, two-factor authentication, something you are and something you know.

If only the designer realised that the warm fuzzy feeling of security does not come from one step in the process, but is a sum off the entire chain. There are multiple chinks in this one. For example, the embedded video in the article clearly shows a huge on screen-display for entering PINs, students queue up, and can easily shoulder-surf… The PIN is even echoed to the screen. Perhaps worst of all, they release a flash video on to the World-Wide-Web of a student (with close-ups of her face) demoing the system, and we can clearly see her PIN (6447).

Whilst perhaps not the most important system on the planet, shenanigans are still to be had for those that are inclined. Also, environment creep is one thing to consider when installing any system. However, I’m more concerned with ’social creep’, what does a system like this teach young adults about security?

student1

student2

Fedora Core 10: Encrypted Swap Partition

February 1, 2009 in GNU/Linux, Information Security | 3 comments

Further research shows that the swap partition in the standard Fedora 10 installation is not encrypted. This means that memory that has been swapped out to disk could be easily read using forensic tools. Worse case scenario could mean that sensitive information, such as account details, or encryption/decryption keys are stored on the disk between reboots.

So what to do? Well, let’s encrypt that bad-boy using dm-crypt. First off, it’s likely you’ve already been using your computer, and so for good measure, you should shred (overwrite) the current swap partition. In order to do that we’ll first need to turn swap off.

# swapoff -a

The default swap partition device will be /dev/VolGroup00/LogVol01. Shred it with:

# shred -v /dev/VolGroup00/LogVol01
shred: /dev/VolGroup00/LogVol01: pass 1/25 (random)…
…

Now, if you already have encrypted other partitions. There’ll be an /etc/crypttab file, if not you should create one, and edit it. Append the following line, and save the file: swap /dev/VolGroup00/LogVol01 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

This will re-create your swap partition at each reboot, and encrypt the partition using a random key. Next, edit the /etc/fstab file, and change this line: /dev/VolGroup00/LogVol01 swap swap defaults 0 0 to this: /dev/mapper/swap swap swap defaults 0 0

Once you reboot the system, the new swap configuration will take effect. Or, if you cherish your uptime, you can initiate an encrypted swap immediately.

# cryptsetup -d /dev/urandom create swap /dev/VolGroup00/LogVol01
# mkswap /dev/mapper/swap
Setting up swapspace version 1, size = 4095996 KiB
no label, UUID=********-****-****-****-************
# swapon -a

Congratulations, your swap partition is now encrypted and is unlikely to yield usable data under forensic interrogation.

Mounting LUKS / dm-crypt Partitions in Microsoft Windows

January 29, 2009 in Geek, Information Security | 2 comments

I blogged earlier detailing my experiences in installation of Fedora Core 10, encrypted internal hard disk drives, and external removable hard disk drives. For some, it’s also necessary to be able to access encrypted removable drives in other Operating Systems, such as Microsoft Windows.

Under Microsoft Windows XP, you will need two pieces of software. A filesystem driver, such as Ext2fsd, and an application capable of opening and closing the LUKS container, such as FreeOTFE. Simply install both pieces of software, and ensure that both are executing. Ext2fsd seems to run at start-up by default, but FreeOTFE does not.

Plug in your LUKS/dm-crypt encrypted USB drive, and open up FreeOTFE. It’s quite tempting to jump straight for the big ‘Mount partition’ button, but instead you will need to go to the File menu, Linux volume, and Mount partition…

Mount Linux Partition Option in FreeOTFE

You will then be prompted to select the partition. Once you do, you’ll receive a prompt for the passphrase, and some additional mounting options. Input your LUKS passphrase for this parition, and change the Mount as option to Removable disk.

Input Passphrase in FreeOTFE

Click OK, and that’s it. The partition should mount correctly. When it comes to unplugging the device, remember to unmount first from FreeOTFE, and then go through the normal hardware disconnection procedure.

« Older entries