Hi
Why not, but this solution is not solving my problem. This just provides
encrypted disk. My main concern, is disallowing the user to run its own
executables.
For answering peoples questions, I don't want to protect this hardware against
governements or very high budgeted crackers. My customer is not the army
neither a bank. This product won't be nuclear missiles, ATM machine or whatever
high security level device. All he want is to disallow its customers to use the
hardware for another purpose than the ones he defines.
I know it's impossible to have a 100% secure system. All I want is to make it
hard enough that it won't worth the price of the device.
The smartcard I'm going to use is home made and tamper-proof. This is the
centralized unit I'm planning to use for the security. I have as well a
specialized processor, with secure memory area and encryption co-processor. All
I'm looking for is how to make everything without having too much impact on the
performance and making it a pain in the ass to crack.
I can sign the kernel, the executables and the libraries. The loader (lilo) can
be in the securized memory of the processor. So before it loads the kernel, it
checks the signature with the smartcard. Then I'm quit sure it's my own kernel
that runs on this machine. From that, the kernel can check the executable by
computing its CRC and compare it with the signed CRC (stored in the ELF
header). The signed CRC is checked by the smartcard itself.
I know that checking the CRC of the executable can lead to slowlyness (have to
load each page of it), but I don't think I have the choice.
For the encryption the international kernel patches could help. I still have to
find a mean to use the smartcard without impacting the performance too much.
I know the user will be able to remove the processor and put another one, but
it will be expensive enough to discourage people doing it.
One other problem that remains is to protect some executables from reverse
engineering, but I don't think its a mandatory feature. I think it's very hard
to perform, because whatever solution I find, the cracker just have to spy the
memory bus to have the ASM code. One can protect the hardware, but its a device
we gonna produce it in million...
This is just the current status of my thoughts. I gathered some idea from some
people and I found an interesting project about signed executable for Linux run
by IBM.
My main concern is to make sure its my kernel that runs on this machine. From
that point I think everything gonna be alright. I think the solution resides in
the processor security features. But I didn't looked at it for the moment. From
want I eared I can have secured ROM memory bundled inside the processed, wich
could solve my loader problem.
Any comment, any idea? Anybody have experience on it?
Thanks to everybody who answered to my initial mail.
Bye.
Quoting [EMAIL PROTECTED]:
> On Fri, 22 Jun 2001, Jim Rees wrote:
>
> > But if you really are concerned about "very skilled hackers" you will
> need
> > significant hardware protection, like a processor with integrated boot
> code
> > or an epoxy potted processor and boot rom module. Even then you won't
> be
> > able to completely protect the system against everyone.
>
> It seems to me, to do completely secure boot protection all one really
> needs is an encrypting disk controller.
>
> Imagine a device that sits between the drive and IDE (or SCSI) disk
> controller. This device encrypts every block of information going to
> the disk, and decrypts every block leaving the disk. The keying
> for this device can be done simply: a keypad is mounted in a
> 5.25" drive faceplate and the key is entered directly to the
> encryption
> device; the underlying computer architecture is not involved.
>
> Now, of course, there are particular issues of concern here .. as to
> how and when the user should key the device, and so forth. And data
> integrity concerns if the user enters the wrong key. But much of this
> can be handled in the same fashion as OS-supplied disk encryption
> methods.
>
> We are just taking the OS out of the loop. The entire drive gets
> encrypted, along with the OS, boot record, and partition table --
> everything. Since the key is never handled by the main computer,
> hacking
> it won't help.
>
> One would need to inspect the encryption device itself while it is
> running
> to extract the key. This can be made very difficult by using secure
> key
> management techniques (ie, moving the key around in RAM, and XORing it
> with known bit patterns, etc. This also prevents "burn in" of RAM and
> takes care of data remanence issues). Also, tamper-proofing the device
> is also a possibility.
>
> Such a system, properly designed and implemented would be secure
> against
> pretty much every attacker. Sure, there are sophisticated ways to get
> by good tamper-proofing in the lab -- but unless the machine is IN the
> lab already, its no good because at power-off the key is gone forever
> (since you did the smart thing and took care of data remanence
> issues).
>
> --
> Michael Graffam ([EMAIL PROTECTED])
>
>
> ***************************************************************
> Linux Smart Card Developers - M.U.S.C.L.E.
> (Movement for the Use of Smart Cards in a Linux Environment)
> http://www.linuxnet.com/smartcard/index.html
> ***************************************************************
>
---
-°) Patrick Valsecchi
/\\
_\_v
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
