Tales from the Crypto

In Defence of the Self-Signed Certificate

Recently I discussed using EFS as a simple, yet reliable, form of file encryption. Among the doubts raised was the following from an article by fellow MVP Deb Shinder on EFS:

EFS generates a self-signed certificate. However, there are problems inherent in using self-signed certificates:

• Unlike a certificate issued by a trusted third party (CA), a self-signed certificate signifies only self-trust. It’s sort of like relying on an ID card created by its bearer, rather than a government-issued card. Since encrypted files aren’t shared with anyone else, this isn’t really as much of a problem as it might at first appear, but it’s not the only problem.
• If the self-signed certificate’s key becomes corrupted or gets deleted, the files that have been encrypted with it can’t be decrypted. The user can’t request a new certificate as he could do with a CA.

Well, she's right, but that only really gives a part of the picture, and it verges on out-and-out recommending that self-signed certificates are completely untrustworthy. Certainly that's how self-signed certificates are often viewed.

Let's take the second item first, shall we?

"Request a new certificate" isn't quite as simple as all that. If the user has deleted, or corrupted, the private key, and didn't save a copy, then requesting a new certificate will merely allow the user to encrypt new files, and won't let them recover old files. [The exception is, of course, if you use something called "Key Recovery" at your certificate authority (CA) - but that's effectively an automated "save a copy".]

Even renewing a certificate changes its thumbprint, so to decrypt your old EFS-encrypted files, you should keep your old EFS certificates and private keys around, or use CIPHER to re-encrypt with current certificates.

So, the second point is dependent on whether the CA has set up Key Recovery - this isn't a problem if you make a copy of your certificate and private key, onto removable storage. And keep it very carefully stored away.

As to the first point - you (or rather, your computer) already trust dozens of self-signed certificates. Without them, Windows Update would not work, nor would many of the secured web sites that you use on a regular basis.

Whuh?

Hey, look - they've all got the same thing in "Issued To" as they have in "Issued By"!

Yes, that's right - every single "Trusted Root" certificate is self-signed!

If you're new to PKI and cryptography, that's going to seem weird - but a moment's thought should set you at rest.

Every certificate must be signed. There must be a "first certificate" in any chain of signed certificates, and if that "first certificate" is signed by anyone other than itself, then it's not the first certificate. QED.

The reason we trust any non-root certificate is that we trust the issuer to choose to sign only those certificates whose identity can be validated according to their policy.

So, if we can't trust these trusted roots because of who they're signed by, why should we trust them?

The reason we trust self-signed certificates is that we have a reason to trust them - and that reason is outside of the certificate and its signature. The majority (perhaps all) of the certificates in your Trusted Root Certificate Store come from Microsoft - they didn't originate there, but they were distributed by Microsoft along with the operating system, and updates to the operating system.

You trusted the operating system's original install disks implicitly, and that trust is where the trust for the Trusted Root certificates is rooted. That's a trust outside of the certificate chains themselves.

So, based on that logic, you can trust the self-signed certificates that EFS issues in the absence of a CA, only if there is something outside of the certificate itself that you trust.

What could that be?

For me, it's simple - I trust the operating system to generate the certificate, and I trust my operational processes that keep the private key associated with the EFS certificate secure.

There are other reasons to be concerned about using the self-signed EFS certificates that are generated in the absence of a CA, though, and I'll address those in the next post on this topic.

Apple Changes Update Policies - Still No Biscuit

As I have mentioned in other posts (Retro-bundling - another suck of the Apple, MacBook Air debuts; iTunes Pesters Me Again, Removing Apple Mobile Device Support, I didn't want iTunes - now I've got iPod, too?, etc, etc), this has long since stopped being an issue for me, because I've removed all the Apple software from my machine as a bit of a protest against Apple's inability or unwillingness to provide me the means to manage my own systems.

Now, I understand that Apple has finally heard some of the complaints from various blogs around the world, and has done something about it.

They have separated the updates from the new software. The new dialog looks like this:

But it still marks the new software by default to be installed.

This is the behaviour that is wrong - okay, so it's now clear as to the difference between an update and a new software, but the key again is that Apple is marking new software for installation from an update tool.

An update tool should be a piece of software that most users say "yes, do whatever", and that doesn't then cause significant additions to the software. By automatically checking new software, Apple is eroding the trust that users will have in the update tool.

Again, I don't mind that they're encouraging users to install Safari - I don't even mind them spending time persuading their existing install base to use it. What I'm perplexed at is that Apple feels that they have to slide it in under the door, rather than sell it to users on its own merits.

And, yes, I'm quite well aware that you could also say the same of any browser that ships with an operating system - except, really, you've got to have a browser shipping in your operating system these days. Yeah, the guys who ship the operating system have an advantage - and they worked hard to build that advantage in the first place. They have a certain momentum behind anything they offer, and even if the system is as open and transparent to all application vendors as it is to the OS vendor, the default installed applications will generally have a larger market share than the 'after-market' tools, just because of users' inertia.

[Note that the paragraph above applies to Apple / Mac / Safari, just as well as it does to Microsoft / Windows / Internet Explorer]

However, I don't think that users' inertia is a cause for sleight-of-hand tactics like retro-bundling.

Think like a bad guy? It's a start.

Cool new site (and blog) from Microsoft - http://securedeveloper.com - and it has a tag line I've heard many times before:

Like that old maxim that "you need to stop fighting fires long enough to tell the architects to stop building things out of wood", thinking like a bad guy is just the first step to developer security.

It's a necessary step, but it's not the final goal.

It's a start - in fact, it's a great start, and I think every developer needs to go through that phase. Many have yet to do so - particularly, it seems, those fresh out of college or programming school.

But I think it's really a catch-phrase for the beginning of becoming a secure developer. It's what you have to tell yourself when you're used to writing code for the sole purpose of implementing features, so that you can get over that mind-set and into the sort of thinking that accepts that your code can be attacked.

But the bad guy has it easy.

He only has to find one way in. He can afford to become an expert on one part of your software, and zero in on it.

Thinking like a bad guy will widen your awareness to the point that you know that incursions can and will happen, and you'll occasionally take better care in your coding. That's a good thing.

But what if you start thinking like someone building a defensive structure?

The defence builder has to find (and limit) all the ways in, and just in case he missed one, he has to find all the ways you can get further in once you're in - he has to become an expert on all parts of the software, as well as something of an expert on the external dependencies - libraries, network equipment, database components, etc.

[After all, we've seen this past week how many sites can get exploited through SQL Injection attacks - and the primary cause for those seems to be web developers who don't know SQL, yet who send SQL statements to be executed at the database.]

You could start thinking like a defender - what alarms should signal the presence, or possibility, of an intruder? What information could an active defender use to verify the intent of a potential intruder? How could you slow down a possible attacker to the point where it's feasible for a human responder to outpace a mechanical attacker?

Maybe you could start thinking like an investigator - once you believe someone has got in, what clues would you like to be left, showing you where the holes were? How can you tell what defences have been useful and what defences were useless? Where was the attacker actively assisted or resisted by your system and software?

Perhaps you could even think like a defence component builder - how can you ensure that you learn lessons from tried and true defences in order to build those lessons in to the next system, or to teach the next set of builders?

Think like the architect of a mediaeval castle - we've gotten used to the idea that mediaeval castles were places of defence, that they sought to be impenetrable bastions behind which the local king, thane, lord or whatever could take refuge and survive. Yet they were also places of business, places of government, places with a function. We need to design programs like mediaeval castles - capable of functioning for business as well as for defence.

SecureDeveloper.com hasn't really gone beyond the first stage of its launch yet, so it will be a while before these advanced topics will be discussed - and I am eager to see that happen.

Can You Write Good Code for an OS you Despise?

No, this isn't another of my anti-Mac frothing rants.

This is one of my "here's what I hate about many of the open-source projects I deal with" rants.

I'm trying to find an SFTP client for Windows that works the way I want it to.

All I seem to be able to find are SFTP clients for Unix shoe-horned in to Windows.

[Perhaps the Unix guys feel the same way about playing Halo under Wine.]

What do I mean?

Here's an example - Windows has a certificate store. It's well-protected, in that there haven't been any disclosures of significant vulnerabilities that allow you to read certificates without first having got the credentials that would allow you to do so.

So, I want an SFTP client that lets me store my private keys in the Windows certificate store. Or at least, that uses DPAPI to protect its data.

Can't find one.

Can't find ONE. And I'm known for being good at finding stuff.

PuTTY is recommended to me. It, too, requires that the private key be stored in a file, not in the certificate store. Its alternative is to use its own certificate store, called Pageant (it's an authorization "Age-Ant" for PuTTY, get it?) Maybe I could do something with that - write a variant of Pageant that directly accesses certificates stored in the certificate store.

But no, there's no protocol definition or API, or service contract that I can see in the documentation, that would allow me to rejigger this. I could edit the source code, but that's an awful lot of effort compared to building a clean implementation of only those parts of the API that I'd need.

What I do find in the documentation for Pageant are comments such as these:

• Windows unfortunately provides no way to protect pieces of memory from being written to the system swap file. So if Pageant is holding your private keys for a long period of time, it's possible that decrypted private key data may be written to the system swap file, and an attacker who gained access to your hard disk later on might be able to recover that data. (However, if you stored an unencrypted key in a disk file they would certainly be able to recover it.)
• Although, like most modern operating systems, Windows prevents programs from accidentally accessing one another's memory space, it does allow programs to access one another's memory space deliberately, for special purposes such as debugging. This means that if you allow a virus, trojan, or other malicious program on to your Windows system while Pageant is running, it could access the memory of the Pageant process, extract your decrypted authentication keys, and send them back to its master.

I'll address the second comment first - it's a strange way of noting that Windows, like other modern operating systems, assumes that every process run by the user has the same access as the user. Typically, this is addressed by simply minimising the amount of time that a secret is held in memory in its decrypted form, and using something like DPAPI to store the secret encrypted.

The first comment, though, indicates a lack of experience with programming for Windows, and an inability to search. Five minutes at http://msdn.microsoft.com gets you a reference to VirtualLock, which allows you to lock 4kB at a time into physical memory, aka non-paged pool. Of course, there are other options - encrypting the Pagefile using EFS also helps protect against this kind of attack, and the aforementioned trick of holding the secret decrypted in memory for as short a time as possible also reduces the risk of having it exposed.

Now I'm really stretching to assert that this single author despises Windows and that's why he's completely unaware of some of its obvious security features and common modes of use. But it does seem to be a trend prevalent in some of the more religious of open source developers - "Windows sucks because it can't do X, Y and Z" - without actually learning for certain whether that's true. Often, X and Y can be done, and Z is only necessary on other operating systems due to quirks of their design.

Back when I first started writing Windows server software, the same religious folks would tell me "don't bother writing servers for Windows - it's not stable enough". True enough, Windows 3.1 wasn't exactly blessed with great uptime. But instead of saying "you can't build a server on Windows", I realised that there was a coming market in Windows NT, which was supposed to be server class. So I wrote for Windows NT, I assumed it was capable of server functionality, and any time I felt like I'd hit a "Windows can't do this", I bugged Microsoft until they fixed it.

Had I simply walked away and gone to a different platform, I'd be in a different place - but my point is that if you believe that your target OS is incapable, you will find it to be so. If you believe it should be capable, you will find it to be so.

Security Koan #3

The security guard phoned his boss in a panic.

"There's been a break-in to the site, sir. The intruders aren't anywhere to be seen, but they've got away with a bunch of equipment."

"Understood - go and look at the perimeter fence, find out where they broke in, and keep watch. I'll be there shortly."

The boss arrived at the site, to find the guard pacing up and down in front of the fence.

"Did you find the hole yet?" asked the boss.

"Not yet, sir."

"Never mind, I'll help you look."

For the next half-hour, they went up and down, searching for a hole in the fence.

Then the boss spoke up:

"Are you sure this is where they got in?"

"No, they got in on the other side of the site."

"Then why are you looking over on this side?"

"Because the light's better here, so we can see more."

Question: Are you monitoring the places most suited for attack, or simply the places easiest to monitor?