The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Encryption

So I've got this new project that has heavy encryption requirements (lotsa reading over the next couple of days to figure out what I don't know about encryption!)

I'm having a fundamental misunderstanding on how "safe" encryption can be.

Here's a simple question: Virtually all encryption that I know of uses a private key somewhere to decrypt the ciphertext. Somewhere, somehow, that key has to be loaded into memory to decrypt the text. No matter where/how the key is permanently stored, it's gotta be loaded into RAM for the app to use it to decrypt with -- no matter what algorithm is used, the key needs to be available to the app, and needs to be loaded into RAM. What's to stop someone from just monitoring the app's memory pool and discovering the key while the app is running?

One could encrypt the private key itself, but that just moves it out one meta-level. Now the key to decrypt the actual key needs to be in RAM and we have the same problem.

Assuming the user is full root/admin and can do anything at all on the machine (including loading any tools they want to monitor RAM), but we don't want the user discover the key. How is this handled?

Off to go do my research now ...
Sgt.Sausage Send private email
Saturday, May 28, 2005
 
 
If you track the keyboard, you got the key.

The Encryption process have some insecure steeps than depend on the system, I recommend to read "The Cryptonomicon" a good novel in my opinion, in this novel one of the chapters have to deal with this problem, he solved not sowing anything on the screen, but it's a novel.

You can write a hail for the application that should manage it, this hail have to  be encrypted outside  the operating systems and run independently from it, is as running a new operating system inside an operating system. It's the way high secure application run.

The only real secure way to encrypt something is not allowing to access it in any way.

Sorry if my English is not as good, but I can not express this area in deep in my mother language.
Roberto Cruz Send private email
Saturday, May 28, 2005
 
 
Sarge,

This is a really large topic (too large for this medium) but might I suggest Applied Cryptography by Bruce Schneier? There aren't many good intros to crypto, but that is one. As the previous poster suggested, there's a lot more to building a secure system than just using a secure cryptographic algorithm. Burglars (usually) do not directly assault locks; they seek to circumvent them. Neither will electronic intruders directly assault the Twofish algorithm or the RSA algorithm. Instead, they will look for system weaknesses to exploit--places where sensitive information is mishandled. So security isn't something you can bolt on--it has to be baked in from the start. But anyway, read the book. There's also a lot of good stuff to read on schneier.com Hope this helps.
John Foxx
Saturday, May 28, 2005
 
 
John Foxx
Saturday, May 28, 2005
 
 
I agree with the previous poster about the book, It's interesting and very pragmatic. For more in deep and academic books I can recommend one but it's in Spanish Digital Cryptography ISBN 84-7733-558-3.
Others that I have in by collection are:

Applied Cryptography
Second Edition
Bruce Schneier
John Wiley & Sons, 1996
ISBN 0-471-11709-9

Practical Cryptography
Niels Ferguson and Bruce Schneier

Modern Cryptography: Theory and Practice
EAN: 0076092025399
ISBN: 0130669431

Handbook of Applied Cryptography
EAN: 9780849385230
ISBN: 0849385237

Some of them are hard to read, need a deep background in maths.

Regards
Roberto Cruz Send private email
Saturday, May 28, 2005
 
 
Sarge,

You frustrations with crypto is justified.  As you have noticed keys exposed to the clear space of RAM are subject to tampering.  Even if the operating system allows for defined user and root protection, a hacker with access to the hardware can put a logic analyzer on the bus and read the keys as they appear on the bus.

This is exactly how the big C-band satellite systems were hacked "back in the day". But I wouldn't know anything about that...

Anyhow. the only way to prevent physical access to private keys is to use somthing like a smart card or secure processor.  It is the only way to limit access to the private key is something like a smart card.

All crypto operations should happen inside the card. Cypher text in, clear text out and vice-versa. If you're really worried about key compromise, this is the only way.

+1 for Applied Crypto.  Not just the Alice, Bob, Mallory scenarios but also the math in terms I can understand.
hoser Send private email
Saturday, May 28, 2005
 
 
Yes, it's impossible to say what you should or shouldn't do without fully understanding the system. I remember a story in the news about a Philadelphia mafia figure--I forget his name--they nailed him by breaking into his house and installing a keystroke logger in his keyboard. The logger weighs about a gram, is smaller than a sugar cube, and stores a million keystrokes. So all the crypto on his computer was useless.

How you approach this problem will fundamentally depend on what kind of device it is. Is it something that fits in a pocket that the user will have on his person at all times? Or is it a permanently installed thing that anyone who can pick locks can theoretically gain access to? These things will fundamentally affect the design.
John Foxx
Sunday, May 29, 2005
 
 
Sarge,

if there are really such "heavy encryption requirements" and you are starting from practically zero, you have a looooong way to go, maybe with a lot of snake oil on your way if you are not careful. +1 for schneier.com - read anything you can find there.

Maybe the most important quotation you should adhere to is: "Security is a process, not a product."
Secure
Sunday, May 29, 2005
 
 
You did not say what the encryption will be used for. It sounds like you are getting ready for coding a software protection scheme a'la Armadillo or whatever it is called these days...

There is more to implementing software protection than knowing all the available encryption schemes. I looked around quite a bit (read all the books people suggested you to read), but sadly, no book will tell you what to do. Most encryption schemes work well over a network, but not when the operator has access to both sides of the equation on a power PC equipped with SoftICE!

Apart from reading crypto books, and if you are indeed trying to create a software protection scheme, I suggest you hang out where the hackers hang out, learn their ways. That way, at least you can stop the lamers. Here is a good place to go to: http://www.woodmann.net/forum/

I also came across a shareware product that was said to have an incredibly well designed protection. I believe it was called "CacheX for Internet Explorer". The protection was such that in order to keygen it, you would have to at least buy one copy of the app and use the key it comes with to decode something else in the application. I read long threads where hackers were scratching their heads for weeks... The app used some sorta modified blowfish. If you can get a hold of the author of the app, maybe he'll tell you how he did it.

Long story short, I think it is practically impossible to make an unbreakable protection, although you can make it very very hard for hackers. Even hardware schemes don't work unless the entire process is in hardware (read no software intervention, reading, processing). Even then, I am sure they'd find a way around it.

Anyway.. Good luck!
dil.b.ert
Sunday, May 29, 2005
 
 
An excitingly written book (packed with anecdotes and WWII code decryption stories):

http://www.simonsingh.com/The_Code_Book.html

(This book is kind of a primer in cryptography and code breaking for non-programmers)
Frank de Groot Send private email
Sunday, May 29, 2005
 
 
"Somewhere, somehow, that key has to be loaded into memory to decrypt the text. No matter where/how the key is permanently stored, it's gotta be loaded into RAM for the app to use it to decrypt with -- no matter what algorithm is used, the key needs to be available to the app, and needs to be loaded into RAM. What's to stop someone from just monitoring the app's memory pool and discovering the key while the app is running? "

Well, you could use a tamper proof hardware backed CSP. Your app can talk to the API for services, but you'll never get the private key, and it will never be transfered to your computers' RAM.

But more to the point, what portion of your threat model brings out "Rogue admin plucks private key from RAM"?
Just me (Sir to you) Send private email
Sunday, May 29, 2005
 
 
Before worying about somebody reading your key from RAM worry about preventing the said RAM area being swapped and thus having the key written on the hard disk.

Sunday, May 29, 2005
 
 
>Well, you could use a tamper proof hardware backed CSP.

And how do you suggest such a "tamper-proof" hardware is built exactly? The hacker wouldn't try to break the hardware encryption anyway. S/he would go after the code that accesses the hardware and disable it!

In order to stop attacks, you have to think like the attacker which is why I suggested hanging out where your attacker would.

Like others said, it all depends on your threat model. If this is a shareware application, depending on how eager the hacker is, you may not have any chance. If you can at least assume that the hacker can't install tools, or slice and dice your application (or whatever it is), you might have a better shot at it.

By the way, if it was easy to protect hardware or create protection using hardware, hackers in Asia couldn't reverse-engineer products, recreate them and sell them for cheap.. ;)
dil.b.ert
Sunday, May 29, 2005
 
 
Diable the hardware and you cannot decrypt the cyphertext.

I do declare, there is a mentality here that is stuck in software.
hoser Send private email
Monday, May 30, 2005
 
 
Thanks all, I know I've got a loooonnnnggg road ahead of me on this one -- lotsa stuff to learn.

Let me address a few of the posts:

==>"Security is a process, not a product."

I agree 100% -- I'm looking to understand "best practice" processes, not purchase an off-the-shelf-silver-bullet-one-size-fits-all solution. Such a beast doesn't exist.

==> The only real secure way to encrypt something is not allowing to access it in any way.

That's the way I'm understanding it after just a day or two of looking into it. That, however, is unacceptable for most folks. The reason we store information is so folks (the right folks *authorized* to use the info) can use the information to do their jobs. Not allowing access is ... well ... not an option.

==>But more to the point, what portion of your threat model brings out "Rogue admin plucks private key from RAM"?

I would think that would be obvious. Any admin can do, basically, anything s/he wants to a machine that they have control of. You've gotta have admins to keep the machines running smoothly -- however, said admins don't necessarily need to be privy to the data flow into/through the machine.

==> So security isn't something you can bolt on--it has to be baked in from the start.

Hence the questions now. We likely won't even start coding for quite some time, and it's reasearch time at the moment. I'm just looking into it to see what we can "bake in from the start."

==>Before worying about somebody reading your key from RAM worry about preventing the said RAM area being swapped and thus having the key written on the hard disk.

I had thought of this. Keeping it out of RAM in the first place (my original question) would certainly keep it from being swapped to disk, no?

Anyway, thanks for all the input. I'll be spending much of the next month immersing myself in this new (to me) world of information security/crytography.

I'll post back some time next month with a followup on how it's all going.

Thanks for the pointers.
Sgt.Sausage Send private email
Monday, May 30, 2005
 
 
There are 3 books by Schneier that I would recommend, and I think when you read them, you'll understand why he wrote them and the order in which he wrote them.

Applied Cryptography (tools) is the nuts and bolts of encryption, the algorithms, the protocols. Other folks have mentioned it, and I think most developers have a copy.
http://www.schneier.com/book-applied.html

Secrets and Lies (systems) is about how encryption fails in systems. Such as putting a $100 lock on a $10 door that protects $1 of loot. Or how somefolks put the same lock on all the doors, so that if/when you break one lock, you break them all.
http://www.schneier.com/book-sandl.html

Beyond Fear (Risk analysis), among other things, shows how to look at security, to determine if it is going to work at all. What makes systems "brittle" and why brittle systems are more problematic than they first appear.
The analysis goes something like:
1 - What assets are you trying to protect?
2 - What are the risks to those assets?
3 - How well does the "security" solution mitigate those risks?
4 - What other risks does the "security" solution cause?
5 - What trade-offs does the "security" solution require?
http://www.schneier.com/book-beyondfear.html
Peter
Monday, May 30, 2005
 
 
Sgt.Sausage:

You came closest when you said this:
I would think that would be obvious. Any admin can do, basically, anything s/he wants to a machine that they have control of. You've gotta have admins to keep the machines running smoothly -- however, said admins don't necessarily need to be privy to the data flow into/through the machine

But can you expand on why you don't trust your own users?  As others have said, if you want the machine to decrypt data but not have the key visible to even an administrator, well that's a big can of worms.
brian's smart ass Send private email
Monday, May 30, 2005
 
 
==>But can you expand on why you don't trust your own users?  As others have said, if you want the machine to decrypt data but not have the key visible to even an administrator, well that's a big can of worms.

Let's put it this way. The *users* are trusted. They are authorized to see/use/manipulate/update/encrypt/decrypt the data. It's the data they need to do their job. There's no problem whatsoever with *users* (authorized users) accessing this data and the appropriate private key(s).

The *admins* are not trusted with this specific data. Access to this data is on a "need to know" basis, and the admins simply have no "need to know" anything about the data in question. End of story.

That's the issue. When an admin can install any old software, at any odd time, then s/he can snoop the RAM, log keystrokes, spy on file access, etc. And you're right. It's a big can-o-worms.
Sgt.Sausage Send private email
Monday, May 30, 2005
 
 
> You've gotta have admins to keep the machines running smoothly -- however, said admins don't necessarily need to be privy to the data flow into/through the machine.

Small point: the question was what part of your threat model is worried about *rogue* admins.

Your assumption, apparantly, is that the people hired to administer the machine can't be trusted, but with many situations, the admins can be trusted to do their job and not actively seek to abuse their position.

On the off chance that you have a point, though: move the decryption to a secondary machine where admin rights are restricted to people with autorisation to read the data. This still means that at least one person has the right to access the data and also has sufficient knowledge to administer the machine, but hey, if that's what you need, it's what you need.

If the admins can be trusted to not attempt to spy, then they're not a threat even though they have the technical ability to hack into the data. If they can't be trusted, then your only choice is to keep the data on a separate machine, with trusted admins.

If the data is this valuable, I'ld worry about the people who have a process to select trustworthy people to see this data but aren't using it to select trustworthy admins - if you know only trustworthy people have access to the data, why can't you select safe system administrators as well?  If you think that you have rogue employees, why aren't you worried about people who have direct access to the secret keys?

Monday, May 30, 2005
 
 
Well, the dedicated hardware suggestions offered will keep the *key* away from even a machine administrator, but with a Windows machine (and I presume *nix), it's simply not possible to keep *data in memory* hidden from an administrator.  It's up to you to decide if this distinction is strong enough to spend time and money on.
brian's smart ass
Tuesday, May 31, 2005
 
 
==>Your assumption, apparantly, is that the people hired to administer the machine can't be trusted, but with many situations, the admins can be trusted to do their job and not actively seek to abuse their position.

No. It's actually the Client's assumption -- and I can't vouch for the kind of folks they hire.

I understand that there's a certain level of trust you need with your admins. I trust mine. The client doesn't trust theirs.

==> If they can't be trusted, then your only choice is to keep the data on a separate machine, with trusted admins.

That's looking like just about the only option.
Sgt.Sausage Send private email
Tuesday, May 31, 2005
 
 
We had a different approach when, my then employer, had to deal with DES and generate credit card PINs. We had what we called a Black Box (that because it was black and we didn't know what was inside), which basically was a box connected through I/O to the computer.

The key was entered separately (the box had its own keyboard) and stored on the box and the pin generation (DES algorithm) was done on the box as well. The box was locked and stored in a safe for most of the time. We had our own access password to programmatically access the box, but only to send the account number and get back a PIN. When the encryption was required, we hooked up the box and we ran the pin generation sequence for 10 mins or so, enough for mailing 100 thousand PINs.

The process itself never had a security breach, but we had mailmen peeking into the mail and running huge bills on somebody else's cards.
coresi
Tuesday, May 31, 2005
 
 
Like all security you need to apply a risk vs. threat analysis before proceeding. Sure you can build the most secure system ever but this will be inheirently cost prohibitive. You are probably going to have to tone down their requirements or if they don't want to listen maybe give them a true quote of what they are asking. Hopefully they aren't stupid and go with a lowest bidder mentality.

Generally your application doesn't have to worry about what happens to the key in RAM or on disk. Important computers are supposed to be physically secure (locked doors, network login, etc) and their networks properly administrated to be secure (firewalls, audit trails, periodic checking of logs, etc.). These factors combined make your application fully secure without you having to worry too much about what you are worrying about.

Tuesday, May 31, 2005
 
 
I agree with coresi, perhaps look to the financial industry for advice on key management. I worked for a company what wrote credit-card processing software and the DES keys for the POS terminals were stored in EPROMs (??) that were erasable by exposure to low-level UV light (think sunlight, or flourescent light). Open the box and, *bing*, the keys are gone. I am no security expert but my biggest concern wouldn't be having the keys in RAM but how are they stored on disk?
A. Nonymous
Friday, June 03, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz