s security value
> > is
> > dubious to say the least, and this guy didn't seem to understand what
> > a
> > trust path even implied.
> >
> > Alex
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> >
> > -
h a system, it's security value
> is
> dubious to say the least, and this guy didn't seem to understand what
> a
> trust path even implied.
>
> Alex
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> - Original Message -----
> From: &q
Ok, it's offtopic here, but I don't think, it is a good idea
to use such policy. Why to protect such thing ??
A good policy is to setup a box and to have a model earning
money on services not on the boxes or the system (linux).
The user can do what ever he/she wants to do, if the user
disconfigu
Patrick Valsecchi wrote:
>
>
> I don't have to store each signature of each bin into the smartcard. I won't
> have enough RAM for that! I'll store inside each executable and library the
> signed crypto hash. The kernel will check if the crypto hash is still the same
> and the smartcard will just
Quoting [EMAIL PROTECTED]:
> On Fri, 22 Jun 2001, Jim Rees wrote:
>
> > Ok, so you have a bunch of executables and a table of pre-computed
> CRC's.
> >
> > No, you have a bunch of executables, and for each you have a crypto
> hash
> > signed with a private key.
>
> Ok.
>
> > You could sto
eheads <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 11:17 PM
Subject: Re: MUSCLE Disk encryption and more
> On Fri, 22 Jun 2001, Jim Rees wrote:
>
> > Ok, so you have a bunch of executables and a table of pre-computed
CRC's.
> >
> > No, you have a bunch of ex
built into their
spec a system to control what programs it can run, they should have.
Peter T
Bristol UK
- Original Message -
From: "Jim Rees" <[EMAIL PROTECTED]>
To: "Smart Muscleheads" <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 10:13 PM
Subject: Re: MUS
On Fri, 22 Jun 2001, Jim Rees wrote:
> Ok, so you have a bunch of executables and a table of pre-computed CRC's.
>
> No, you have a bunch of executables, and for each you have a crypto hash
> signed with a private key.
Ok.
> You could store the public key in the secure rom, but this guy wa
Hi,
It's still crude, but we have a paper on smartcard based secure
booting:
http://www.citi.umich.edu/techreports/
Boot up from secure ROM, and use a smartcard to make sure kernels and
application binaries are good.
--
Concentration .. Naomaru Itoi
*
Ok, so you have a bunch of executables and a table of pre-computed CRC's.
No, you have a bunch of executables, and for each you have a crypto hash
signed with a private key.
You could store the public key in the secure rom, but this guy wants to use
a smart card, presumably because he wants t
Thanks you, this is a very good recapitulation. Even better that my first
mail ;-)
Quoting Jeremy Impson <[EMAIL PROTECTED]>:
> On Fri, 22 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > On Fri, 22 Jun 2001, Jim Rees wrote:
> >
> > > But if you really are concerned about "very skilled hackers" you
>
On Fri, 22 Jun 2001, Patrick Valsecchi wrote:
> 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
> th
Aren't CRC algorithms easy to reverse?
Sorry for the sloppy terminology. Obviously this has to be a cryptographic
hash, not just a crc. But I still think performance will not be a huge
issue.
dumaguete# ls -l /bsd
-rwxr-xr-x 1 rees wheel 2172784 Jan 25 16:11 /bsd
dumaguete# time md5 /bsd
On Fri, Jun 22, 2001 at 10:00:35PM +0200, Patrick Valsecchi wrote:
> The user will be able to change the code, that's not the matter, but it wont be
> able to run it on my customer's hardware. That's the point. And I don't this it
> goes against any law neither any license.
>
> I'm sure it does
The user will be able to change the code, that's not the matter, but it wont be
able to run it on my customer's hardware. That's the point. And I don't this it
goes against any law neither any license.
I'm sure it doesn't go against any GPL spirit. It's even possible that my
source will be par
On Fri, 22 Jun 2001 [EMAIL PROTECTED] wrote:
> 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 modul
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.
This shouldn't be slow at all. You have to load the pages anyway, right? I
hope you're not thinking about sending the entire kernel to the card, that
w
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 custo
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
I don't know about the rest of it, but a former colleague of mine worked on
a secure booting system using a smartcard. I don't see anything on his web
page about it but you could contact him directly.
http://www.citi.umich.edu/u/itoi/
But if you really are concerned about "very skilled hackers"
um you've got a lot of requirements that Linux may or may not be able to
meet. I think the biggest problem you're going to have is that if the user
has hardware access, the game is over anyway. Really, truly, and completely
over. Trusted hardware tends to combat this inability to be able to
wi
21 matches
Mail list logo
