Results 1 to 10 of 71

Thread: The UEFI SecureBoot Saga For Linux Continues

Threaded View

  1. #29
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,413

    Default

    Quote Originally Posted by allquixotic View Post
    That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system. Also, this method does not provide any way to verify that all of the binaries present on the system are genuine: if they were somehow modified through an exploit of some kind, you wouldn't be able to know.

    It's like if you send an HTTP request to a remote website without SSL enabled, and a response comes back, you don't know if someone in the middle has messed with the data somehow. You can't verify that it is coming from the endpoint that you sent your request to. But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message.

    This is what secure boot does, but instead of network data, it verifies executable code on disk.
    "But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message."

    this is just wrong because SSE is based on "Trust" and the "Trust" part is the vulnerability because in the past the "Trust" centers allow untrusted people to violate there "Trust" to hijack your "security" (DigiNotar CA certificate abuse) source: http://support.mozilla.org/de/questions/872516

    only PGP is save from this kind of attack. '


    "This is what secure boot does, but instead of network data, it verifies executable code on disk"

    now you get the same problem on the hardware side the Criminal "Microsoft" and the Criminal "Government" get the power of "certificate abuse)

    now a example you store your 1 million dollar of Bitcoins on your "server" and you trust "LOL-UEFI-LOL" then the "Good" Government make Bitcoins against the law but only to rape the bitcoins and sell them to earn money for buying weapons to start a "war"

    now the government with the name USA go to there company with the name MIcrosoft and do a certificate abuse and now what do you get?

    UEFI is only power in the hand of microsoft and govnernment insteaf of power in your hand!

    because UEFI is based on "Trust" but first rule in security is: "do not trust"

    back to my unbeatable (unbeatable for the real evils like government)solution:

    "That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system."

    this is wrong because this is only the security of the lowest level you build a virtualization with hardware emulation because of this the "Virus" always manipulate the emulated hardware and never the REAL hardware

    " Also, this method does not provide any way to verify that all of the binaries present on the system are genuine:"

    this is also wrong because the virtualization emulation do have a 1on1 copy of the original files so they can compare it all the time no way to escape this one.
    Last edited by Qaridarium; 06-01-2012 at 12:08 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •