2

Suppose Alice and Bob are communicating using secure channel and both use symmetric key algo (AES) for encryption/decryption. The scenario is like 

1. Alice encrypt data M1 with secret key K and sends cipher text C1 to Bob.
2. Bob receives cipher text C1 and decrypt it to get plaintext M1.

3. Bob encrypt data M2 with secret key K and sends cipher text C2 to Alice.
4. Alice receives cipher text C2 and decrypt it to get plaintext M2.

These sequences are followed repeatedly till communication ends.

Both Alice and Bob are using Linux System with latest kernel.

I have following questions with respect to security point of view.

  1. If an intruder somehow manages to gain root privileges on Alice's system, will the intruder be able to capture the plaintext M2 stored in memory while Alice performs decryption operation ?

  2. In case the secret key K is stored in memory (I'm not sure** whether it is) during encryption/decryption is performed, then is Intruder also able to retrieve secret key K the same way?

Edit 1:

From both answers , it is known using MEMORY DUMP , it is possible to recover secret key as well as plaintext.

Can you explain with example?

Improve this question
3
  • As a very simplistic example, you could debug the application with something like gdb (gdb can also open memory dumps), and inspect the values used by the variables, including secrets. In practice, gdb relies on the application being compiled with debugging information, so it may not work on all applications, but this doesn't mean removing debugging information will make an application secure - it just means an attacker needs to reverse engineer information about the structure of the application that the compiler didn't include.
    – James_pic
    Jun 22, 2017 at 9:58
  • Am I right - while decryption is going on, memory will be dumped and later using gdb to open memory dump to read value of secret key?
    – bholanath
    Jun 22, 2017 at 10:36
  • Yes, that would be one way. Or gdb can attach to a running process, and do similar things.
    – James_pic
    Jun 22, 2017 at 15:17

2 Answers 2

Reset to default
5

This question is missing the implementation context - i.e., the software that implements the algorithm in question. With that caveat, the answers are YES and YES. Intruder with root priveleges can extract both plaintext messages as well as the key.

Recent implementations are a super conscious of this - and try to wipe the key from memory ASAP (interpretations of this "ASAP" vary). It is however practically impossible to bring down the exposure to zero for both the message and the key.

At best, the key can be protected in a hardware assisted solution (SGX or a HSM) - or even a separate decryption solution (not as implied by you - decryption on the same system/kernel.

The message itself cannot be protected as long as it is required for use in that system. Some obscurity can be managed though. e.g., some software use techniques that beat a simple "strings" analysis. I wish I stored the reference somewhere. Unable to link it here.

Improve this answer
3
  • thanks for answering. Can you show how to use Memory Dump to recover secret key/plaintext ?
    – bholanath
    Jun 22, 2017 at 6:40
  • @bholanath: Did you even understand what he wrote?
    – Zaibis
    Jun 22, 2017 at 11:21
  • 1
    @bholanath It depends on the application, not just the OS, where the key is stored. You cannot just dump memory, go to location Z and point out the key or anything like that.
    – Maarten Bodewes - on strike
    Jun 22, 2017 at 20:57
3

Yes to both questions. It doesn't matter much which kernel you're using, or which OS. The decrypted plaintext will be in memory, unless you're using some very specialized system that sends the plaintext away one byte at a time, sanitizing memory structures afterwards.

It would be possible to obfuscate the plaintext (e.g. storing it through a scramble mapping, for example a Feistel network or a square S-Box), but the scrambling parameters would need to be in memory, which makes this "security through obfuscation" and thus no security at all.

The same applies to the secret key, which moreover has to be available throughout decryption; which, in turn, makes sending the plaintext away and clearing up afterwards somewhat pointless (the ciphertext is assumed to be known by the attacker through interception. Once K is recovered, the game is very much over whatever Alice and Bob may do).

Improve this answer
11
  • thanks for answering. Can you show how to use Memory Dump to recover secret key/plaintext ?
    – bholanath
    Jun 22, 2017 at 6:41
  • 2
    Unless a part of the plaintext is known, so that you can use strings and grep, you have to have an idea of what the program's memory structures look like. There are tools to examine dumps and sort out which areas belong to which process. Without more information, one can't really be more precise than this.
    – LSerni
    Jun 22, 2017 at 7:05
  • 1
    I think your best bet is the Volatility framework (volatilityfoundation.org/releases). But better be clear: if you are a wannabe Eve, as things stand you've very little hope of success.
    – LSerni
    Jun 22, 2017 at 10:48
  • 2
    You can not prove that the data can not be recovered. In a basic implementation 'strings dump | grep keyword' can be used to prove recoverability. root may even inject malicious code in both crypt and decrypt processes and intercept their I/O. That is enough to demonstrate that in such a scenario you have no security.
    – LSerni
    Jun 22, 2017 at 12:43
  • 1
    "As everyone in security field say about if you have root permission you can do any harm. I feel with root permission one can do harm by deleting ciphertext , but not able to decrypt the ciphertext." Hmm, we're telling it to you again, but as we are part of the "security field" I'm kinda wondering why we go through the trouble in the first place.
    – Maarten Bodewes - on strike
    Jun 22, 2017 at 21:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .