Robert Millan wrote:
> On Sat, Feb 28, 2009 at 12:18:17AM +0100, phcoder wrote:
>>> If the code that does the authentication is loaded from the encrypted
>>> partition,
>>> without being checked, this is true, but we assume, that core.img is already
>>> loaded (and checked), so the authentication
phcoder wrote:
>>
>> I'm no crypto expert, but I was under the impression that when the
>> data is
>> encrypted, measurement comes "for free": if someone tampered it, you'd be
>> unable to decrypt. Is this correct?
>>
> It's not. Encryption is permutation
> E_{key,sector} (P) -> C
> Which permutes
Robert Millan wrote:
> On Sun, Feb 22, 2009 at 02:27:25PM +0100, Jan Alsenz wrote:
>> If we could agree on this, then I think we could find a way to extend the
>> GRUB
>> module system to fully allow this.
>>
>> From my point of view the minimal needed features
phcoder wrote:
> Jan Alsenz wrote:
>> phcoder wrote:
>>>> Oh, I want!
>>>> If I remember correctly, exactly this broke the protection on some
>>>> game console!
>>> Do you refer to Xbox crack based on King kong game? For once their goal
&
phcoder wrote:
>> Oh, I want!
>> If I remember correctly, exactly this broke the protection on some
>> game console!
> Do you refer to Xbox crack based on King kong game? For once their goal
> is the evil one. For second the problem is a buffer overflow in
> rendering engine, not the not checking p
Vesa Jääskeläinen wrote:
> Jan Alsenz wrote:
>> Vesa Jääskeläinen write:
>>> I do like the idea what some protected systems use, they sign the binary
>>> (in our case .mod file and kernels of loaded OSes). Now in that scenario
>>> it is responsibility of the
Vesa Jääskeläinen write:
> Hi All,
>
> Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it
> to the topic first... (I am already waiting for summary of that other
> discussion at some point ;))
>
> Jan Alsenz wrote:
>> Next I think we can agree, tha
phcoder wrote:
>> Ok, but your already talking of a specific solution here. My
>> conclusion would
>> be: The hooks need to be able to determine the filename, that is
>> currently read.
>>
> And then also where it comes from but some files may have different
> filenames. IMO the solution work indep
phcoder wrote:
>> - hooks for any disk read (not sure if write is necessary)
> This way how trusted grub does it is an ad-hoc solution which results in
> a MESS. They just try to hash and rehash everything without design. So
> if grub is instructed to load all modules in a directory and filesystem
Hello!
Alright, lets try to end the pointless (in the sense, that I guess noone here,
including myself, will change their opinion anytime soon) TPM discussion and get
something done.
First I'd say we can agree, that we don't agree on whether/how to use a TPM.
I don't know about you, but I can per
Robert Millan wrote:
> On Sat, Feb 21, 2009 at 10:17:02PM +0100, Jan Alsenz wrote:
>>> First of all, I think it's a poor approach, because there's no way to
>>> garantee
>>> the TPM is doing what it's supposed to (can you read its source code? h
Robert Millan wrote:
> On Sat, Feb 21, 2009 at 10:43:16PM +0200, Michael Gorven wrote:
Just to clarify, are you objecting to the use of TPM on principle and
because you don't want to encourage use of it, or because you think this
specific use (trusted boot path) is dangerous?
>>> I c
Hi!
I don't want to be picky here, but you know that remote attestation is simply
sending signed hash values?
The important thing is that the receiver has trust in the protection of the
private key.
So if you build me a coreboot/GRUB version with a trusted boot chain I can
happily implement a rem
Robert Millan wrote:
> On Tue, Feb 10, 2009 at 07:02:56PM +0100, Jan Alsenz wrote:
>> Hello!
>>
>> I just noticed, that the pc linux loader (loader/i386/pc/linux.c) always
>> truncates the kernel command line to less than 256 characters.
>> Well since I needed a
Robert Millan wrote:
> On Sat, Feb 21, 2009 at 03:20:39PM +0100, Jan Alsenz wrote:
>>> "remote attestation" is only useful when you want to coerce others into
>>> running your (generaly proprietary) software. I hope this is not what you
>>> want to do.
>
Robert Millan wrote:
> On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote:
>> On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz
>> wrote:
>> [skip]
>>>The TPM can proof to another party, that the PCRs have certain
>>> values (of
>>>
Robert Millan wrote:
> On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote:
>> While TPM may open a door for corporations to prevent machine owners
>> from having control over their machines, in this instance I do not see
>> another way to solve Alex's problem.
>
> There's an easy way
>>> If not, who checks the MBR?
>> This can't be done by grub because it happens before any part of grub is
>> loaded. to verify grub you need to rely on vendor/platform-specific
>> mechanisms.
>> I personally find "tpm without tpm" more attractive because it can be
>> easily reused on another plat
phcoder wrote:
>> It's not complete SHA-1, but the rest should be just a constant offset.
> I already said how it differs from standard one. If you feed padded
> byteswapped data to it and then byteswap the rsult back you obtain
> exactly normal SHA-1. But as I said if size is fixed it's compeletel
Hi!
Wow, cool work!
It's not complete SHA-1, but the rest should be just a constant offset.
But I'm still not sure, what you are trying to do here, is the MBR your root of
trust?
If not, who checks the MBR?
Greets,
Jan
phcoder wrote:
> Hello, as promised I wrote an mbr which performs SHA-1. T
Vesa Jääskeläinen wrote:
> In case it will get some day in. I would propose that you make own MBR
> code like that gets compiled to own img file like tpmboot.img (512
> bytes). Then you can just provide img file for tool chain. You are
> probably throwing code away anyway from normal mbr boot code.
I agree too!
Multiple methods are interesting and everything that can be, should be placed in
modules.
But some parts of a trusted boot chain need to be in the MBR, etc. which is
mainline code (regardless of how how you build it).
The way I have implemented my version of the MBR right now is wit
Alex Besogonov wrote:
[skip]
>>> As far as I understand - no.
>> Actually - it is.
>> Check the "TCG PC Client Specific Implementation Specification for
>> Conventional
>> Bios" or "TCG PC Specific Implementation Specification" at
>> https://www.trustedcomputinggroup.org/specs/PCClient/
>> and loo
Hi!
Alright, lets try to make sure everyone is talking about the same things here.
First of all a TPM is not just some kind of secure memory only accessible from
early BIOS, it basically is a small computer. You can only send it commands, and
it can "decide" to reject them, e.g. if you try to rea
Hi again!
I checked the boot protocol documentation and found that since version
2.06 (kernel 2.6.22) there is a field with the supported command line size.
I updated my patch to respect this field if it is present, otherwise the
maximum 4k buffer is used.
Greets,
Jan
Jan Alsenz schrieb
y of avoiding any arbitrary limit at all wothout modyfiing boot protocol?
> Thanks
> Vladimir 'phcoder' Serbinenko
> Jan Alsenz wrote:
>> Hello!
>>
>> I just noticed, that the pc linux loader (loader/i386/pc/linux.c) always
>> truncates the kernel command lin
Hello!
I just noticed, that the pc linux loader (loader/i386/pc/linux.c) always
truncates the kernel command line to less than 256 characters.
Well since I needed a longer command line, I fixed this problem.
I found a patch on this list from last year (
http://lists.gnu.org/archive/html/grub-deve
27 matches
Mail list logo
