I need to work with encrypted variables so that if the os is not secure or a attavk at the ram is carried out it is hard to access sensitive data.
So my question is how that would be possible?
Related
Hi I am trying to develop a small Wifi manager, and I have one question:
I need to encrypt the profile file when saving it in the disk, and decrypt it when loading it.
I will use a pass-phrase to do that, so how can I store my pass-phrase:
- If I store it in a file, it's to easy to dump
- If I hardcode it, it will be visible somewhere in my binary
- I am under WindowsCE, and I don't know if there is a secure store to save Data?
- I know that under Linux, we can have the trust store, and with tuning some permissions only 'root' will have access to it, and this is enough for me, is there any possibility to do something like that under WinCE?
Regards,
Microsoft's Wireless Zero Config stores the WiFi keys in a registry key defined in eapol.h. [HKLM]\Comm\EAPOL\Config
The string is encrypted using CryptProtectData with the CRYPTPROTECT_SYSTEM flag.
I'm trying to understand what happens when I use a password-protected private key to generate a message digest.
I read here that password-protected private keys are just encrypted using a password-based symmetric key.
Once I enter the correct password, how is a digest generated without exposing the unprotected private key?
At some point the cryptographic primitives in your code will need to access and use the actual value of the key. There's simply no way around that. In a simple analogy, you cannot compute a + b if you don't know a.
The big question concerning secure software design thus boils down to how long sensitive information will persist in an unprotected state. Any sort of password caching is your enemy here, but even if neither the password nor the decrypted key are explicitly cached, they're still in memory at some point. Freezing a computer with liquid nitrogen can keep the memory content intact for a considerable amount of time, and forcing a swap-to-disk is another problem.
Good cryptographic programs should take care to overwrite the memory content as promptly as feasible and minimize the amount of time that sensitive information is retained in readable form. This requires careful analysis of which information is critical (e.g. the user's password input), and platform-specific knowledge of memory management (e.g. can you request non-pageable memory?).
It all depends on your threat model - which sort of attack do you need to protect against? If a rootkit monitors all your memory, you might be in trouble, though that rootkit would probably just read the user's password entry from the keyboard anyway.
This is a complicated issue, and there's extensive research into secure hardware design. In general, the more access an attacker has to your machine, the more likely it is that she'll be able to read sensitive data. Good design can only strive to minimize the surface of attack.
At some point the key has to be available in memory for use by the crypto algorithm.
There have been interesting attacks to try and grab valuable information from memory. One I read about involved plugging a device into a Firewire controller and using direct memory access to poke around for interesting things.
http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation
It's entirely possible that either a program with necessary privilege to read the memory location holding the key, or hardware utilizing DMA, can grab a private key from RAM.
Generally yes, once decrypted the key will be stored in system memory as cleartext until the application or operating system marks it's address as re-writable. With PGP Desktop, it's possible to manually clear the cached private key, a nice feature I wish more applications offered.
Yes, it is exposed in RAM, and unless the operating system supports protection of memory against paging, and the application uses that feature, the private key can be paged to disk "in the clear." Development tools and active attacks can look for it in memory.
This is one reason specialized hardware cryptographic modules exist. These perform operations with the private key in their tamper-proof memory space; the application can never access the private key itself, it delegates cryptographic operations to the device.
Setup
I have a SQLite database which has confidential user information.
This database may be replicated on other machines
I trust the user, but not other applications
The user has occasional access to a global server
Security Goals
Any program other than the authorized one (mine) cannot access the SQLite database.
Breaking the security on one machine will NOT break the security on other machines
The system must be updatable (meaning that if some algorithm such as a specific key generation algorithm is shown to be flawed, it can be changed)
Proposed Design
Use an encrypted SQLite database storing the key within OS secure storage.
Problems
Any windows hack will allow the person to access the key for all machines which violates goal #2
Notes
Similar to this method, if I store the key in the executable, breaking the security will comprimise all systems.
Also, I have referenced windows secure storage. While, I will go to an os specific solution if I have to, I would prefer a non-os specific solution
Any idea on how to meet the design goals?
I think you will need to use TPM hardware e.g. via TBS or something similar, to actually make a secure version of this. My understanding is, TPM lets the application check that it is not being debugged or traced at a software level, and the operating system should prevent any other application pretending to the TPM module that it is your application. I may be wrong though.
You can use some kind of security-through-obscurity kludge, but it will be crackable with a debugger unless you use TPM.
hello
i have an educational software that should be installed on different PCs across the enterprise.
my program is using a 5000 text, xml, html files as source of it's content. i don't want my source to be tampered with, copied or used illegally. what i intend to do is to encrypt my source seperately and then put the encrypted files in a folder inside of my app so later my app can read and decrypt each file that is requested by user. the app will be installed and used anywhere.
but the problem is that to secure and store the encryption key inside my application i have to use a key container while as far as i remember(correct me if i'm wrong) they're machine based and can't be used on different machines while i need my key to be fixed for all the installed copies on any PC. i know a lot of softwares using such a architecture but i don't know how do they do that.
any idea?
If you put the key on every PC (and you have to if you want them to be able to run your software) then everyone will have it and the encryption is pointless.
but the problem is that to secure and store the encryption key inside my application
Yeah, you can encrypt that key with another key and then turtles all the way down... What you are trying to do is impossible. Don't waste your time. You will gain no security whatsoever and the only thing you will do is waste cycles and annoy users making their computers slower.
I am setting up a server where some important code will reside. I want to make sure the code is unreachable, in case the HD is stolen. Well I know you never can be sure, but reasonably secure.
Which method could I use?
How to i.e. mount a crypted filesystem at bootup without human interaction?
Thank you very much for your help.
I do not know if any of the encrypted filesystem solutions support this, but one solution would be to have the server contact another server to get the key. You could even imagine splitting the key between several servers, so the server would have to contact n out of m servers to get the key.
If you place the servers in different locations that would make you safe against (n-1) out of the servers being stolen.
An attacker would however of course be able to get access to the encryption key if he performs the attack while the server is still connected to the network, but this implementation would make you secure against simple theft.
Mounting an encrypted file-system without human intervention will ultimately weaken your security. The thief would just need to steal your server. It is perfectly doable with any Linux based system using dm_crypt. There are many online tutorials showing you how to do it.
If this is for a file-server, you may want to consider using FreeNAS. It is a BSD based NAS operating system and it includes the ability to encrypt the disks, amongst other things. You will need to enter a password through the web-interface to mount the disks.
The open source TrueCrypt creates a virtual disk within a file and mounts it like a real drive, or it can encrypt an entire drive. Encryption is transparent and fast. I have used it; it works in real time. It might make things easier.
What you want is called Full Disk Encryption. A complete partition/filesystem is encrypted, it is decrypted by the OS (or 3rd-party-software) when it's mounted.
There are many implementations, and at least MS Windows & Linux have it as part of the OS.
See the Wikipedia article for details.
Being able to mount it w/o human intervention could be problematic; after all the whole point is that you cannot read the HD without human (i.e. your) intervention :-). You might be able to do this with some hardware token, but then that could also be stolen. So that requirement might not be doable.
Without human interaction is possible using a hardware token but you need to guard against someone stealing the token along with your server.
You could accomplish some safety with built-in GPS and a 10-minute backup battery or something (forget the key if power is lost for >10 minutes or the server is moved). You can make it work somehow but it will be insanely expensive.
You propably want a less involved solution like this:
Boot from a regular partition
Set up encrypted swap with a randomized key on startup (important!)
Set up /tmp and similar locations on an encrypted partition or in RAM (important!)
Mount the encrypted data partition by logging in over ssh
Still human intervention required, but you can stay at home while doing it.
Thank you very much for your helping answers.
I'll try a truecrypt container wich uses several distributed keyfiles (and no password).
A script will retrieve the keyfiles, then mount the volume, then delete the keyfiles.
Since we are only a small bunch, another option could be to programatically crypt/decrypt the data on the client side just before writing/reading. But this seems to me somehow tiresome.
Then, what about having a keyfile on a terminal server?
So many questions!
Thank you once more for your help.
Now... I just remembered about cold boot attacks. Do we really need guns? Are we that doomed?