Re: Can a program prove it's own integrity?
From: Bill Unruh (unruh_at_string.physics.ubc.ca)
Date: 05/20/04
- Next message: Bill Unruh: "Re: Limiting RC4 to "40 bit" strength"
- Previous message: David Eather: "Re: http://www.cerberus-sys.com/~belleisl/infosec.html"
- In reply to: AE: "Re: Can a program prove it's own integrity?"
- Next in thread: Kiuhnm: "Re: Can a program prove it's own integrity?"
- Reply: Kiuhnm: "Re: Can a program prove it's own integrity?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 20 May 2004 16:56:43 +0000 (UTC)
]Kiuhnm wrote:
]> AE wrote:
]>
]>>This is where the idea comes from:
]>>
]>>I wanted to protect a complete harddisk - encrypting disk driver,
]>>modified bootloader to run the operating system from the encrypted
]>>disk.
]>>
]>>The weak point is the bootloader: If it is changed an attacker can
]>>read the password as I'm typing it and all security is gone.
Of course a program cannot tests its own validity. The program could
simply have been completely replaced by another one. A program can test
its own validity against certain prescribed types of changes (in some
cases even changes to the testing program section itself) this comes
under the scope of error detection/correction, which is a very large
industry in many many regimes. However they can only test against
certain kinds of errors.
So yes, the boot loader could have been replaced, and the boot loader
itself cannot check that.
]>
]>
]> Write a self-decrypting pre-bootloader that, in order to work properly and
]> eventually decrypt the real bootloader on the hard disk, needs some random
]> data.
]> Put the pre-bootloader and the random (or compressed cryptographic) data on
]> a floppy disk. Your floppy disk must be *full* and the data nearly
]> incompressible (just use a state-of-the-art compressor).
]> The encrypted part of the pre-bootloader, once decrypted and executed, must
]> enter the highest privilege level (e.g. Ring 0), use time-stamp instructions
]> and execute *many* difficult-to-emulate operation (the code could test the
]> "protected mode" functionalities..., execute pmode BIOS extension, etc...).
]> The code will also check the floppy disk hash and print "expected secret
]> strings" on the screen.
]>
]> You could use a low-density floppy disk (it's more efficient because you
]> have less data).
]>
]> You should:
]> 1) (physically) disconnect the hard disk,
]> 2) (physically) write-protect the floppy and insert it,
]> 3) turn on your computer,
]> 4) insert the password,
]> 5) wait :-)
]> 6) Examine the screen and decide if the floppy disk is genuine.
]> If you think it's genuine:
]> 7) turn off your computer,
]> 8) reconnect the hard disk,
]> 9) turn on your computer,
]> 10) etc...
And the new bootloader installed by the enemy could simply print the
requisite data to the screen. Since all you test is whether it prints
the correct stuff, it prints the correct stuff. There is no reason why
the correct stuff printed on the screen has anything to do with it
running all those tests.
Besides, this is hardly "program tests itself" If you have a floppy you
can stick in you can put testing code on that floppy to test if the boot
loader has been altered.
- Next message: Bill Unruh: "Re: Limiting RC4 to "40 bit" strength"
- Previous message: David Eather: "Re: http://www.cerberus-sys.com/~belleisl/infosec.html"
- In reply to: AE: "Re: Can a program prove it's own integrity?"
- Next in thread: Kiuhnm: "Re: Can a program prove it's own integrity?"
- Reply: Kiuhnm: "Re: Can a program prove it's own integrity?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|