RAM encryption

top_hattop_hat Posts: 4Registered Users ■□□□□□□□□□
Does anyone know a good encryption SW that can do file, directory, disk, and RAM encryption?

Thanks

Comments

  • JDMurrayJDMurray Certification Invigilator Surf City, USAPosts: 11,339Admin Admin
    I don't think there is a software-only way to transparently encrypt data in memory (RAM) that is independent of the operating system. Data in memory is en/decrypted by the code that put it there. True transparent encryption would be performed using specialized hardware, such as TPM, and an API to access the data.

    As for data in other places, Truecrypt works as securely as anything.
  • beadsbeads Posts: 1,439Member ■■■■■■■■□□
    Don't forget BitLocker, WinMagic or even the venerable PGP as well as TrueCrypt. All do file and directory based encryption. I cannot imagine the complexity of SW based RAM encryption. How do you propose reading your own memory if you need to decrypt said memory for litterally "where"?

    As far as data in motion, RAM is not considered to be in motion at this time.

    - B Eads
  • JDMurrayJDMurray Certification Invigilator Surf City, USAPosts: 11,339Admin Admin
    I assume there are secure OSes that do on-the-fly RAM encryption that is transparent to the programs using RAM, but with the access speeds required I can't imagine that being done without the use of specialized hardware.

    Data in RAM would be data in process. Data has no need being in RAM unless its there to be processed by software.
  • dijital1dijital1 Posts: 64Member ■■□□□□□□□□
    top_hat wrote: »
    Does anyone know a good encryption SW that can do file, directory, disk, and RAM encryption?

    Thanks

    In a nutshell, "No." Not for software that executes on general computing processors like x86/am64 anyways. Some companies that attempt to protect their IP tend to use executable cryptors to offer a layer of protection. The problem with 99% of them is that they don't protect the code once it's in memory. So you'll have an encrypted blob on disk but once you run it, the decryption stub executes converting the ciphertext to its plaintext machine code and then hands control over to the loader to map the executable into memory. At that point an attacker can simply **** the process to disk and recover the machine code.

    The closest you can come to that kind of protection you're talking about is by using something like Themida. It offers an "execution proxying technology" that if configured correctly, allows individual code blocks to be decrypted before being given to the CPU for execution and then re-encrypted once that block of code returns. There's quite a bit of overhead involved in using it but if you care that much about making it difficult someone to steal your IP, you probably value security more than having the code execute as quickly as possible.

    Full disk encryption offers protection against someone getting access to the data assuming the machine is completely powered off when the attacker gets physical access to it. For all practices after the system is booted the contents of the disk are in the clear.

    Hope this helps.
  • JDMurrayJDMurray Certification Invigilator Surf City, USAPosts: 11,339Admin Admin
    dijital1 wrote: »
    At that point an attacker can simply **** the process to disk and recover the machine code.
    That's basically how the encrypted payment card data was retrieved in from the POS computers in the Target breach. The POS Malware scanned for payment card numbers in the unencrypted process memory, dumped what it found as text to a file on disk, and then sent the file to a command and control server for later retrieval. Keeping the payment card data encrypted for a long as possible isn't good enough if it's processed in unprotected memory space. It seems like a custom hardware solution is the best bet.
Sign In or Register to comment.