|
|
|
| Authored by: Anonymous on Friday, June 01 2012 @ 02:24 PM EDT |
I also see it this way...somehow I think inverting public keys will be worth
someone's while.
The basic problem is one of observability....we get these black boxes, and we
can't observe ALL of the outputs.[ Reply to This | Parent | # ]
|
| |
| Authored by: davecb on Friday, June 01 2012 @ 05:56 PM EDT |
The key's just an easily changed chunk of data in a stored program
computer, defined as one in which the program is part of the data in the
machine.
To jailbreak a Windows 8 computer, change the stored program. Make
it accept your key, make it contain your key, or, easiest of all, make it follow
the "accept" branch whatever the key test
says.
--dave ---
davecb@spamcop.net [ Reply to This | Parent | # ]
|
| |
| Authored by: Tufty on Friday, June 01 2012 @ 06:57 PM EDT |
All that a key security system will do will delay the time before the system is
cracked. Once again users will be hampered while the crackers run amok. One
question on this, does the computer need to talk to a 3rd party to verify the
key? If it does then what happens to computers kept off the net for security?
---
Linux powered squirrel.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, June 01 2012 @ 10:09 PM EDT |
As far as I can tell from the comments, nobody in this thread seems to
understand how public/private key pairs are used for code verification. The
private key *never* leaves the secured confines of the signer (in this case
Verisign). The way it works is that:
- a cryptographic hash of the executable is calculated,
- that hash (and perhaps some additional vendor information) is encrypted by the
CA using the private key to form the code signature
- the encrypted hash/signature is appended to the executable
- the BIOS/boot/program loader re-calculates the executable hash
- the BIOS/boot/program loader uses the public key to decrypt the hash in the
signature
- the BIOS/boot/program loader compares the two hashes and rejects the
executable if the calculated and signed hashes don't match.
The steps listed above would surely be used for verification of the boot loader
and kernel. Now maybe they've added an extra/intermediary step where a symmetric
key is used to encrypt and decrypt hashes for individual executables for an O/S
(i.e. once the boot loader and kernel are loaded) to reduce the higher overhead
of doing asymmetric en/decryption when loading each executable module. You would
then use public/private encryption on the symmetric key instead, and that
symmetric key could change for each O/S. However that approach carries added
risk since you would then have the unencrypted symmetric key in memory and, if
it were somehow accessed, it could be use to legitimize a malware loadable
module.
Public and private keys are matched pairs - you won't have multiple public keys
working for a single private key. All UEFI BIOSes will have the public key that
matches the Verisign/MS private key. To add support for a Linux or Red Hat
specific private key, then all BIOSes would need to add the corresponding public
key to accept executables signed by the Linux/Red Hat private key. In the long
run, I think Linux vendors should work with the BIOS vendors to see if it's
possible to incorporate their public key into the BIOS so that they don't have
chase down each of the motherboard/PC manufacturers to add the Linux public key.
However Red Hat's approach makes the best of a bad situation under the current
time constraints.[ Reply to This | Parent | # ]
|
|
|
|
|
