Hi, While reading this, I came up with a relatively simple (and therefore relatively easy to circumvent) way of storing the key. Now, this is by no means secure - as said before, you won't be able to reasonably secure your data, if you don't have access control over the hardware. The idea would be to use the BIOS to store the key and read the key on boot from a BIOS adress - this would require some work modifying the BIOS, but since a key is at best 256 bits long, you only have to 32 bytes of unused memory in your standard configuration (possibly can even re-use existing BIOS values, without writing anything into it. Of course any determined attacker can easily read the bytes out of the BIOS, using the same way you do it, or take it from memory - but at least the disk won't boot when plugged into another machine. Whiole security through obscurity (which this is), is no real security, it does protect you from some less determined attackers. If you build a custom kernel, which checks for a BIOS checksum, and then reads the prefedfined bytes for the key, you should be able to force an attacker to at least debug the kernel binary, to get to the adresses, or run it in a debugging virtual machine, as well as obtain the correct BIOS. This of course won't help a bit, if you're already expecting cold-boot attacks. What you're trying to do is essentially DRM, and that is a big problem, essentially you can't solve it without dedicated hardware support (like HDCP for blu-ray, as prime example) and even then you need essentially perfect implementation of your scheme, or keys will leak. Also, I agree, that you will probably need professional assisstance to implement anything that will remotely provide some protection, as anything that can be done via standard linux tools can be undone by those same tools. Best of luck with your endeavour! Rick On Thu, 14 Jan 2010 17:51:49 +0100 Arno Wagner <arno@xxxxxxxxxxx> wrote: > On Thu, Jan 14, 2010 at 02:24:48PM +0100, Xavi Montero wrote: > > Hi all. > > > > First, congrats to the coders that have made this available. > > > > Second, a question from a newbie in dm-crypt. > > > > THE QUESTION IN SHORT: > > > > How do I boot a protected system but not having to type the key at any > > point? It is an unattended system. > > Simple answer: You cannot. More complex answer: You need > a tamper resistant device to hold the key. This means > you have to build or buy special hardware. What depends > very much on the threat you face. > > > JUST A BIT MORE: > > > > The PC runs our software, but is located in another place, with another > > people who don't have to have access to the system itself, but need the > > machine to be local there. We reach the system over a DSL, via ssh. > > > > FULL DETAILS OF WHY I ASK THIS: > > > > While I use Linux from a decade+ ago, I've never had the need to crypt > > data on hard disks. Now I have a need, I initially though dm-crypt could > > be the solution but I'm not sure of how to do a thing that maybe others > > have already been exploring. > > > > PROBLEM: > > > > I sell radio advertising of third-party broadcasters. We are automating > > all and radios put a PC on each studio and we control it remotely. It is > > needed locally because it is from there where the audio-spots are > > casted, but we control when and where remotely. The software to put in > > their PC is Linux-based and is ours. > > > > The radios are thousands of Km away and we do all on-line and by phone. > > There are radios I've never seen in person. > > > > What I do up to now is to release a bootable ISO, the radio downloads it > > and burns a CD. Boots from CD and the installer formats, installs and > > then boots from the HD. The radio must then insert their net > > configuration and config their router so I can access the machine from a > > DSL line over ssh. > > > > Up to here, we have not used encription, because I trust very much the > > people on the first stations I have had representation for. > > > > Now we are growing. We have 46 stations from other owners. As the > > station number increases, I start to loose control of what they do with > > that software and I don't want they "copying" the HD to give it to > > "friends" and another person building a business that compete with me > > based on my own system. > > Ah, here we have the risk you want to protect against. Now we can > talk. Still not too specific. What exactly do you want to protect > on the target system? The ads? The software that does them? Why > is the system worth anything without your maintenance/administration? > I would think that a copy is pretty useless to another radio station. > > If your threat is a competitor stealing the technology, then how > difficult is it really to build it from scratch? And do not forget > that the central side is not included in any stolen box. > > > I therefore thought to crypt the partitions. If radios give the full HD > > to a friend... hey! doesn't matter, if their friends do not know the > > passphrase, will not be able to read the contents even having a > > full-copy. > > > > To avoid people entering into the live system, it does not have any > > tty's avaiable (no one can log from the Keyboard) so no way to "run the > > system and enter on it". The only way to copy our soft is to extract the > > HD and plug into another computer as secondary, or boot that machine > > from a liveCD. > > > > SOLUTIONS I'VE BEEN THINKING BUT I DON'T SEE FOR CLEAR: > > > > a) I thought of install dm-crypt and set some kind of "auto-mount". Of > > course if passphrase is as simple as "blank", then no secret is there, > > and for the "friend" it is easy to try and enter. This is not a > > solution. A passphrase should be there. > > > > b) Nevertheless, if I have a passphrase, -as that is in a REMOTE > > location from me- I would have to ask the admins to insert the key by > > hand, thus they would know it. They could give the phrase to their > > friends. No sense. The passphrase must be secret (at least up to certain > > point -ie: not "clearly known"-). > > > > So if the system must boot, must have a passphrase and nobody has to > > type it, only 3 solutions appear in my mind: > > > > 1) A script contains somewhere instructions with the plain-pass-phrase. > > Although this difficults from "plugging and seeing content", this is not > > too difficult to track or discover. > > > > 2) A script or binary-exe contains some kind of bainary version of the > > phrase. Performs "mounting". While rigorously "crackable", it is not > > "obvious". For a person knowing enough as to do this, can "crack" the > > system, but probably a person having such knowledge would build a clone > > of my system from scratch instead of intending to re-use it. > > > > 3) A script "queries" the passphrase to a central sever at the > > boot-time. This way if they "copy" the HD, the pass is not ther. Of > > course this has a hughe-big-disastrous disadvantage: If the "key-server" > > (in our office) fails and the radio has to reboot that machine they will > > not be able to boot. Even not having the passphrease on the HD, I really > > dislike this method because of the dependencies. > > > > THE QUESTION: > > > > What do you reccomend? > > > > Thanks to everybody for helping, and again to the coders/maintainters of > > dm-crypt for the job done. > > > > Xavi. > > I think as long as you do not control what hardware this is done on, > you have no chance at all with enecryption, all you can do is to > make it a tiny bit more difficult. > > Even though there is no tty, what does prevent the other side from > installing your software in a virtualized environment and then just > reading the key from a memory image? Right, nothing. Even physical > access to memory is possible, just crash the machine, reboot fast > without memory test and read the memory. Cooling the memory before > that often makes it retain its contents for several minutes. And > you can repeat this attack any number of times if it boots up and > decrypts automatically. > > Next risk: How should the boot image identify which computer it is on? > As long as you do not solve that, the image can be copied, regardless > of encryption. If your passphrase generator is not very careful before > it unlocks something runs ans checks all the boot code and the whole > susyem running so far, an attakcer could just run it with, e.g. a > modified dm-cryopt that stores/prints the passphrase. > > I think (and the histroy of IT security would agree) that this problem > can basically only be solved with a closed system with physcal > intrusion deteceion, i.e. ship them a system in a stell box they > cannot open. Intrusion detection is typically done by having some > sensors that notice opening and attacks (light, IR, UV, extreme > temperature, strong vibration, holes drilled in the chassis, etc., > and you need all of them) and that then wipe a RAM that is kept up > by batteries that also power the intrusion detection system. > > Depending on the level of effort an attacker is willing to spend, > you may get away with a box that is hard to open (e.g. a small safe). > You may also be able to do something contractual, so that they > have to give this box back and if it was opened it gets expensive > for them. The attack on this is to claim it was stolen. > > My Advice: > > You need to analyze clearly what your risk is and what it means > in financial loss when the risk is realizes (the attack succeeds). > Then you need to understand the ciosts end risk reduction effect > of possible countermeasures. Only then can you decide on > what to do. Remember that IT security is risk management. That > in particular does mean it does not deal with absolute security, > but with risk reduction, i.e. reducing expected cost of attacks. > In some situations the best course of action is to do nothing at > all! > > Some possible advice (may not be applicable as you have not stated > what you want to actually protect against): > > - Forget about encryption. It will not help and will cost a lot > to implement and support (remember it has to be tied to that > specific hardware and boot software to be worth anything). > > - Implement a remote tamper detection scheme. You can, for example, > do checksums over the ROM, the Disk serial, the CPU serial, all > kinds of application files, etc.. If it has been messed with, > verify what has happened. Have a contractual penalty in place > in addition. > > - Do only the initial intallation with the ISO and do the rest > (the software you want to protect) over the network. Customize > it for each customer so that you can identify who leaked it > if leaked copies turn up. Have a legal reaction in place for > that, e.g. a contract penalty. > > - Have the system both phone home (so that copies have a chance to > alert you) and require phone-in maintenance (and stop working > after, say 2 weeks without a phone in). > This depends on what you actually want to protect against, i.e. > is it better to have a copy work initially and then fail > unpredictably, or is it better to not work at all? It could > also exhibit random failures if unmaintanies (the sneaky option). > > - Think about shipping a welded shut box or a locked safe to > the customer with the hardware inside. Would be expensive > and may or may not be worth it. May also give the hint to > the customer that whatever is inside may be valuable. > > You may also want to get IT security consulting on this if > the risk to you from a successful attack is bad enough. I > would offer my services commercially, but better get somebody > that understands the local cultural and legal boundary > conditions. This type of consulting is not cheap, so whether > it is worthwhile having really depends on the potential > financial damage to you. > > Arno _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
