Linked by Thom Holwerda on Thu 31st May 2012 11:11 UTC
Thread beginning with comment 520517
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2011-01-28
Thanks for answering my questions, but with regards to those, what is your source for the information? I'm not willing to assume this works like microsoft's normal code signing process without something authoritative that specifically says so. I couldn't find any of the information specific to alternate bootloader signing on the microsoft links.
I still find it unfortunate that secure boot was designed to control *who* has access instead of being a useful tool for owners to determine their machine has been compromised by bootloader malware. From the sounds of it, it won't be difficult for someone to sign a trojan directly or exploit someone else's buggy code. And from what we already know, "secure boot" will just accept the microsoft key without question.
After the fact revocation is better than nothing I suppose, but it gives very little confidence against a targeted attack, where a trojan is unlikely to be discovered by a victim for whom secure boot has failed.
Sorry mjg59, these last few paragraphs aren't addressed to you... I'm just extremely disappointed that we're going to be stuck with this instead of a more valid and open solution.