memory safety for encrypted, sensitive data

im writing a server in c++ that will handle safe connections where sensitive data will be sent.

the goal is never saving the data in unencrypted form anywhere outside memory, 开发者_如何学Pythonand keeping it at a defined space in the memory (to be overwritten after its no longer needed)

will allocating a large chunk of memory and using it to store the sensitive data be sufficient and ensure that there is no leakage of data ?

From the manual of a tool that handles passwords:

It's also debatable whether mlock() is a proper way to protect sensitive information. According to POSIX, mlock()-ing a page guarantees that it is in memory (useful for realtime applications), not that it isn't in the swap (useful for security applications). Possibly an encrypted swap partition (or no swap partition) is a better solution.

However, Linux does guarantee that it is not in the swap and specifically discusses the security applications. It also mentions:

But be aware that the suspend mode on laptops and some desktop computers will save a copy of the system's RAM to disk, regardless of memory locks.

Why don't you use SELinux? Then no process can access other stuff unless you tell it can.

I think if you are securing a program handling sensitive data, you should start by using a secure OS. If the OS is not secure enough then there is nothing your application can do to fix that.

And maybe when using SELinux you don't have to do anything special in your application making your application smaller, simpler and also more secure?

What you want is locking some region of memory into RAM. See the manpage for mlock(2).

Locking the memory (or, if you use Linux, using large pages, since these cannot be paged out) is a good start. All other considerations left aside, this does at least not write plaintext to harddisk in unpredictable ways.

Overwriting memory when no longer needed does not hurt, but is probably useless, because

• any pages that are reclaimed and later given to another process will be zeroed out by the operating system anyway (every modern OS does that)
• as long as some data is on a computer, you must assume that someone will be able to steal it, one way or the other
• there are more exploits in the operating system and in your own code than you are aware of (this happens to the best programmers, and it happens again and again)

There are countless concerns when attempting to prevent someone from stealing sensitive data, and it is by no means an easy endeavour. Encrypting data, trying not to have any obvious exploits, and trying to avoid the most stupid mistakes is as good as you will get. Beyond that, nothing is really safe, because for every N things you plan for, there exists a N+1 thing.

Take my wife's work laptop as a parade example. The intern setting up the machines in their company (at least it's my guess that he's an intern) takes every possible measure and configures everything in paranoia mode to ensure that data on the computer cannot be stolen and that working becomes as much of an ordeal as possible. What you end up with is a bitlocker-protected computer that takes 3 passwords to even boot up, and on which you can practically do nothing, and a screensaver that locks the workstation every time you pick up the phone and forget shaking the mouse. At the same time, this super secure computer has an enabled firewire port over which everybody can read and write anything in the computer's memory without a password.