Re: RE: A continual revolution

[Blue Boar <BlueBoar () thievco com>]

Gage wrote:
>       The problem is really BEFORE the encryption is initiated, which is
> the time the user depresses the keyboard and the time that the data (input
> key from the keyboard), is passed to the encryption algorithm.  It is pretty
> simple with a system-wide O/S intercept, including the keyboard, to
> intercept the keyboard chip and know what key was depressed on the keyboard.
> I have sent an example article, with a quote from the article:

But that's not the threat this is trying to protect against.  DRM
concerns aside for a moment, the reason for wanting to have a
palladium-enabled keyboard is so that you can have the secure kernel
side be the only one that gets to talk directly to the keyboard, and
decide which keystrokes get copied over to the insecure side.

The example of why you want to this is you want the PGP/GPG
implementation running on the secure side to be the only program that
gets to see the keystrokes for your passphrase.  It then passes the
decrypted email over to the insecure side for processing.  Or maybe even
displays it to the secure display, all from the secure side.

It's not a bad concept, if you are able to use it fully from your OS of
choice.

And yes, your secure kernel and all user processes running there have to
be perfect with no vulnerabilities, or else you can break into the
secure side.  If you break a userland app, you may required signed code
to execute, not clear.  If you break the secure kernel, then obviously
game over.

This is based on information I've gathered about previous
Palladium/NGSCB plans.  I understand that some plans have changed, and
we won't know exactly what gets implemented until it is implemented.

                                        BB
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave