Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> They will of course try to get the key from a running system, but thats also something you should most definitely have in your threat assessment.

1. I have yet to see any indication that this is the case.

2. If you assume such technical skill in your adversaries, you must figure that they could just as well open your servers and read the file system keys right off the memory by running wires to the memory bus. In which case Mandos is no worse than no Mandos.



Putting wires on the memory bus is not really needed.

>1. I have yet to see any indication that this is the case.

Taking memorydumps of running systems have been state of the art for about 10 years. There is a heap of commercial forensic software which are used for extracting everything from bitlocker to back then truecrypt. In 2014 it was published that the German police used ElcomSoft as well as Passware, both capable of extracting keys from running machines. I doubt you even need experts for that anymore. Police officers were already on alert to prevent you from shutting down your devices years ago in cases where they assume that there might be evidence on them. I mean we are living in a world where the police is cloning smartphones in routine controls. And on the more sophisticated site, where the police is allowed to infect suspects of even low level drug dealing with trojans. The police isnt stuck in the 90s and they are aided by a rather large sector producing forensic software as well as spyware.

I understand that your product offers great convenience, however its only reasonable to point out, that the need to put in your password after the device was shut off is not a problem but working as intended. Encryption will only protect you if the device is turned off. Circumventing this is not necessarily a good idea.

edit: You also dont have to assume law enforcement. The tools are also affordable for private entities and marketed towards for example towards private detectives.


Even if your adversary have access to the latest and most sophisticated state-of-the-art tools, and have the budget for having technicians to use them, Mandos still does no harm; i.e. does not reduce security. And Mandos is not meant to defend against this; Mandos is instead meant to get people who are not using encrypted disks to start using encrypted disks, since Mandos fixes the (in my opinion) most annoying problem with using encrypted disks.

You are, in effect, arguing about whether encrypted disks are useful at all, which is a debate I’m really not getting into at this time, since it has nothing to do with Mandos.


>You are, in effect, arguing about whether encrypted disks are useful at all

No at all, encrypted disks are very useful, you just cant show anyone the content.

The sole purpose of encrypted disks is to prevent somebody else from reading them once they are turned off. Your product turns them back on and makes it readable again without your interaction. Turning off those devices is however the only protection you had. So now you also need to turn off a second server.

And once someone has access to your running machine he can read it. Be it with simply copying the files or getting the key via some software with a big "HACK" button. https://www.elcomsoft.com/efdd.html


> Turning off those devices is however the only protection you had. So now you also need to turn off a second server.

I’m not sure I follow. If I understand you correctly, you want to have a panic button to press in case of physical intruders, and without Mandos, the power button of a server served this function, and your’re worried that Mandos makes you lose this button? Not to worry. The simplest solution is to have two local servers be the Mandos server for each other, each enabling the other to reboot unattended, and the panic button would be the power button on the power strip powering both servers. Once both servers are off, the system is effectively locked.

If you insist on having a remote Mandos server (which is not really the use case it was made for, but it is supported), you could always automate some button to signal the remote server to disable (or outright remove) the client, thereby denying all access to the secret password. The Mandos server process is controllable via D-Bus, so any program can be made to signal the Mandos server in this way.

With a programmable power strip you could even have a single button doing both things. So there’s your panic button back.

> And once someone has access to your running machine he can read it.

That has nothing to do with Mandos. Anyone with physical access to a running machine can already, in theory, access the memory and get the encryption key. Mandos introduces no additional threat from a theoretical sophisticated attacker.


There is several parts to this, depending on the threat model.

One is the scenarios where both machines are turned off during theft or fishing expeditions from legal enforcement. In this case running encryption, any encryption, is better than no encryption, and Mandos allow the administrator to install it once and forget.

I take it that your concern is that someone has turned off a machine and forgot the Mandos server, and then a time later a attacker has capabilities to break into the encrypted running machine through unrelated vectors. Mandos do not protect against attackers that has capability for breaking full disk encryption on running machines.

The threat model where we assume the attacker can break into an running machine that is encrypted looks very different. Devices that has mitigation against this tend to have in my experience things like movement sensors, light sensors and GPS, with plenty of kill switches that fry the internals if anything look at it funny. Those kind of threat models are fun, and I enjoy talking to those kind of engineers that work on such servers, and to them I don't recommend Mandos.

Where I do recommend Mandos is to the administrator that for reasons are not physical near the server that they maintain. Maybe they work at multiple buildings or travel. They have servers with sensitive services which won't be turned off for long periods but still need reboots once in a while, and yet goes unprotected because there is no one available to write in a password at the physical location.

A other scenario is when people want to treat a location as safe and want protection in transit. In that setup the client can be treated as any unencrypted device for all purposes except when taken outside the local network, at which point it behave like an encrypted device where the person carrying might not even have access to the password. In theory this makes for a great method to transport a work laptop between offices in different countries, booted into an throwaway operative system.

As with any security, thinking hard about the threat model is essential. What are you protecting, who is the attacker, and what are the risks.

Disclosure: I am also a co-author of Mandos.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: