Security Laboratory

Security Laboratory

Security Laboratory: Cryptography in Business Series

We are grouping papers in this series to focus on the many facets of data encryption.

Other Related Articles in Security Laboratory: Cryptography in Business Series


An Interview with Oggy Vasic, Vice President of Software Development, ERUCES Inc.


By Stephen Northcutt

Thanks for investing the time! Oggy is responsible for security oriented software development at ERUCES Inc., and his product is used in high security installations of the US intelligence community. We appreciate his time in being involved in the series.

Oggy, can you tell us a bit about the approach you used to develop the ERUCES architecture?

Certainly, Stephen. I was pondering the question of how do we, as human beings, protect an object that is important to us?

We generally lock it up somehow, did I get that right Oggy?


Sure Stephen, or if we increase the scale, we build a wall around it and then defend the wall. Such an approach has been working splendidly for thousands of years. A castle is a great example of this. But, as it is inherent to every security solution, besides solving the main problem, it introduces a few of its own. In order to defend the wall, you have to man it; thus you have to put people you trust between the wall and the protected object. Unfortunately, the defenders occasionally change their allegiance - the (in)famous problem of the trusted insider. Additionally, you may want occasionally to show the object to the outside world. To do that, the wall has to be punctured with gates. Visitors will be checked at the gates and, once inside the walls, to preserve security their freedom of movement should be restricted.

The trusted insider problem is fairly intractable too, Oggy; next thing you know we need something like secret police. And the gates tend to be vulnerability points.


Exactly! After all, what could possibly go wrong? Plenty of things: evildoers will try to make holes in the wall and, once inside, pretend to be the trusted ones; or they will simply pass a check at a gate and then try to impersonate the insiders. And if an actual object that one wants to protect is corporate data, there are some other considerations. In order to stay competitive, companies must cooperate, so modern business processes have to cross corporate boundaries. In the Internet age, that means data has to do the same. But a business partner today quite often becomes a competitor tomorrow, leaving your information outside your "wall" without any chance of protection.

Yes, we apparently just had that happen here in Hawaii where I live. Allegedly Mesa airlines approached Aloha Airlines about partnering and then used the information they gathered to open up a competitor service they are calling Go airlines. Aloha is suing them, but the damage is done and it will be a long time till the court case is settled.


Good illustration Stephen, and the problem is still more complex. There is another consideration; the workforce itself is very mobile nowadays and workers are carrying a multitude of portable devices. And even the savviest can't usually say what pieces of corporate data get synchronized to what device. So, how to protect data in the modern, distributed world that doesn't lend itself nicely to wall-building? Pondering this problem we realized that existing solutions are trying to make security as a property of systems or networks. We decided to make security as a property of data itself. It may sound bombastic, but an approach to do so has existed for thousands of years. It is encryption. When we put all mathematics aside, encryption is a method of risk transfer. If you want to protect a data item, you create a key then lock the item with the key!

I am not sure it is really risk transfer, I think it is actually risk mitigation, but regardless, this is a large issue. And I agree encryption can be a valuable tool, physical security can only get you so far, even with a multi layer or ringed approach.[1] With respect to the growing problem of mobile devices, organizations need to determine what their risk appetite[2] is and it varies issue by issue; then they need to make certain senior management buys into that risk appetite statement or if an event occurs, heads may roll. So, Oggy, how does crypto change the dynamic? I encrypt the item . . .

... and then instead of protecting the item, you need to protect the key. By designing a system that keeps keys which protect distributed data in one centralized repository puts the wall-building back in the picture. Because the keys that need protection are in one known place this gives us a chance to build a formidable wall. There is another interesting consequence; whoever controls the key, controls the data. This is quite convenient when we need to open our data to partners/competitors. Even after sharing protected data, by denying access to the key, we effectively revoke the data. Should we protect everything with one key? If it becomes compromised, everything is compromised, so obviously we need to use multiple keys. Should we use a fixed set of keys? Business logic of potential sharing dictates that every logical item has to have its own key. It also demands that keys be stored separately from data. And finally, for the whole concept to be useful, data will need to be decrypted on demand, so the data has to contain a link to its key. Because data has to be backed up as well as the keys, and the ways of backup media are rather mysterious, we want to make this link hidden; so, even if one has both the keys and the data, it can't be inferred which key was used to encrypt a particular data item.

But you would need a rock solid architecture, correct? This could get complex quickly, can you help me understand the mental model?


All of these thought experiments led us to a theoretical solution, a system that would generate a key on demand for every logical item, then:

  • Encrypt the item,
  • Encrypt the key,
  • Encrypt the link between the item and the key.
Because three encryptions are involved, we called it Tricryption. It stores keys in a repository it controls. What is persisted there are essentially encrypted key-key identifier pairs, where a key identifier is just a random number. After being protected, data is returned to the business realm augmented by a Hidden Link, an encrypted key identifier that functions as an encryption receipt.[3]

HiddenLink
Data=
JnAEE5BfboGmt+oyA== HL9IbzJsfmyAs31p0ZScLoZ9epE=
Protected data in the business realm.

KeyID Key
v+PMC0OgbCSYR2Xb+rUIYA==
BfLeCYlbE0GjrRLWBjmrCw
Records in key database.

Well Oggy, I can certainly see why the intelligence community is interested in the concept of Tricryption. It will be fun to watch as your company tries to go to market with the concept. If you think of it, give us a shout in six months or so and let us know how you are doing.


1. July 10, 2007 http://www.sans.edu/resources/securitylab/281.php
2. July 10, 2007 http://www.sans.edu/risk_appetite.php
3. July 10, 2007 email from Vasic to Northcutt, special note, due to language issues, much of this interview is based on a powerpoint file describing Tricryption sent as an attachment in this email