1

My threat model is that, the adversary has physical access to the machine and root access. I don't care about any data on the system other than a couple python scripts that contain sensitive information.

I will be protecting these text files against read access by encrypting with gpg with the key stored inside a yubikey. The second layer of protection will be using Fernet inside python's cryptography module. It's built on AES in CBC mode with a 128-bit.

With these measures, will my text-file/scripts be protected against read access? If not, any recommendations?

EDIT: During every session, I will clear my memory cache, unmount the volume containing the script files, and the turn off the machine.

The attacker will only have physical access to my machine in the turned-off state. For example if I accidentally lose it. There is the potential of remote attacks when I'm interfacing the machine in a public network (public-wifi) for example. But I will have proper firewall setup to prevent any kind of remote attacks.

So in my mind, the only reasonable attack vector for the adversary is to have physical access. Correct me if I'm wrong here please.

The second assumption I'm making is that the attacker will have some 0 day exploit that allows them to gain root access to the machine (starting from the turned-off state).

The decrypted js or python scripts will be used when I'm interfacing with public wifi. So presumably the keys used to decrypt will be stored both in my yubikey and in the memory(temporarily). Decrypt keys will not be stored on disk. So to prevent memory dumps, I will clear cache before turning off the machine after every session.

Improve this question
4
  • If the adversary has full access to the machine no read or write operation are safe. This also includes any encryption or decryption done on the machine or even the temporary storing of secret information in memory. Assuming that you want to actually execute the script on the machine and not just storing an encrypted version of it, then the temporary storage of the decrypted secrets in memory is needed though.
    – Steffen Ullrich
    Jun 16, 2022 at 4:06
  • @SteffenUllrich when the adversary gets access to my machine, it will be after the memory cache is cleared, volume unmounted, and machine is turned off. I would clear the memory cache before turning off the device each session. In public wifi-situations, I would have proper firewall setup to prevent remote-code execution. And the initial scenario I described in OP is a hypothetical where I lose my device and the attacker somehow brute forced their way into root or got priv escalation thru a 0 day vulnerability(worst case). Does that change your initial security assessment?
    – an0nhi11
    Jun 16, 2022 at 5:27
  • These are crucial information which should be part of the question and not hidden in a comment. Please edit your question accordingly, specifically to show when the attacker might have access and when the decrypted information is needed and where the decrypted information might be stored (memory only, on disk, ...)
    – Steffen Ullrich
    Jun 16, 2022 at 6:13
  • @SteffenUllrich I edited my OP. thanks
    – an0nhi11
    Jun 16, 2022 at 6:35

1 Answer 1

Reset to default
2

The information in the script should be sufficiently protected by the proposed encrypted provided that

  • it is properly implemented
  • and all access is done before the adversary gets access to the device

Once the adversary got access to the device it cannot be trusted anymore since the attacker might have changed software in the device to behave differently. For example the cryptography library could be changed to log the results of encryption to disk or directly send it to some device on the internet.

Better security could be achieved by not only encrypting the specific parts of the script but use full disk encryption combined with secure boot, to ensure the integrity of the system.

Improve this answer
1
  • 1
    Additionally, an adversary with physical access can alter the hardware (e.g. install a key logger) which may not be detectable. The device should be trusted unless you have physical control of it.
    – Andreas F
    Jun 17, 2022 at 8:52

You must log in to answer this question.

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