Thursday, 20 October 2011

Fake it 'til you break it

So me and my Dad have the same initials (and obviously last name).  It was never really an issue until I got older and started receiving mail of my own.  It was common for me to open mail that I thought was addressed to me, but it was actually for him, and vice-versa.  Fortunately is was usually fairly clear from the context of the mail who the mail was actually for, but the fact remained that it was impossible to tell who the mail was for just by looking at the outside.

The same problem can occur when you use cryptography to protect information.  Encryption or signatures are often used to protect data so that an application can be confident that data that leaves its control can't be altered.  However, the keys used for this protection may very well be used by other parts of an application, for a very similar purpose.  So what happens if someone replays some protected data from one part of an application to a different part of that application?  After all if the data is protected in the same way it will pass any signature checks and decrypt successfully.

Initially it might be tempting to say, "use different keys!".  That would work, but it could also drastically increase the number of keys you have to manage.  Hopefully you know that the real problem with using cryptography is usually how to securely manage the keys.  For this reason keys are often re-used.

So what could go wrong if an attacker uses data that is impersonating other data in an attack?  Who knows?!  It clearly is totally dependent on the data that is protected and the implications of it being trusted by the wrong application.

There is a simply solution though, all you have to do is ensure that where your part of an application uses the data, you provide a way of identifying that the data belongs to you.  This could be as simple as adding a unique fixed prefix to the data you protect and ensuring when you recover that data you confirm the prefix is correct.

It's a bit of an odd attack, but I can guarantee that any attacker that suspects some data is encrypted will be injecting that encrypted data into any other place where encrypted data is being used.

Pick 'n' Mix Mitigations

I was just perusing the July/August 2011 IEEE Security & Privacy magazine and I came across an interesting article "Developer-Driven Threat Modeling: Lessons Learned in the Trenches" (pay-walled unless you are a member of the IEEE) by Danny Dhillon, that talks about EMC's experience implementing a threat modeling strategy in their organisation.

What I found particularly interesting was the section on how they mitigate risks that have been identified by their threat models.  From the article:
The software security field has matured
over the past decade, and a wealth of information
on how to mitigate many common issues is widely
available—but the quality and consistency of that
information varies.
And in reference to the approach EMC came up with:
The mitigation strategies include changes
that developers can make during the design phase
as well as downstream coding, documentation, and
maintenance considerations. Where appropriate, the
guidance includes sample code and references to rec-
ommended toolkits and frameworks. It also includes
alternative mitigations along with their implications
and when they should or shouldn’t be considered.
From the brief description of their approach it seems to me that it nicely complements the MMM ideas I have been espousing, which fundamentally are based on the same concerns (the immature mitigations that are readily available on the web).

They definitely do not have a "one size fits all" all approach to their mitigations, and you could almost refer to it as Pick 'n' Mix (albeit a bit flippantly).  The point is (and I'm reading between the lines here) is that they have different solutions for different situations, but solutions tailored to their needs, and the solutions are not just technical but address a range of activities from the development life-cycle.

It's good to see a company taking a well-rounded approach to their mitigation strategies, let's hope more companies can learn from them.