Protecting the Operating System

Discussion in 'Computer Security' started by Ricardo, Sep 24, 2006.

  1. Ricardo

    Ricardo Guest

    Hello,
    I have just come to the conclusion that the only way to protect the machine
    with free physical access to anauthorized personnel is... to encrypt it.
    Unfortunately it seems that this can be done only the lonely by DriveCrypt
    software which costs a lot. It's wonderful stuff indeed allowing to encrypt
    the drive with authentication feature at the pre-boot level! The encryption
    seems excellent AES-256 algotithm. It's only drawback (except for the price)
    is that it doesn't see Linux partitions (not to mention that it doesn't run
    on Linux)which makes them liable to potential attack. It looks like for now
    only Windows operationg system may be securely locked unless you run Linux
    as a VMware guest system on the DriveCrypted Windows host. I wonder what are
    your experiences with respect to securing the stand alone box with
    uncontrolled physical access, like at the University (my case).
    P.S. Have just noticed free stuff called CompuSec PC Security Suite which
    seems both Windows and Linux compatible though as compared to DriveCrypt it
    uses weaker encrypting algorithm AES-128 and looks like is much slower. I
    cannot wait to hear your comments.
    Kindest regards,
    --
    Ricardo
    Ricardo, Sep 24, 2006
    #1
    1. Advertising

  2. Ricardo

    Vanguard Guest

    "Ricardo" <> wrote in message
    news:c6eac$4516d82a$57cf8a7f$...
    > Hello,
    > I have just come to the conclusion that the only way to protect the
    > machine
    > with free physical access to anauthorized personnel is... to encrypt
    > it.
    > Unfortunately it seems that this can be done only the lonely by
    > DriveCrypt
    > software which costs a lot. It's wonderful stuff indeed allowing to
    > encrypt
    > the drive with authentication feature at the pre-boot level! The
    > encryption
    > seems excellent AES-256 algotithm. It's only drawback (except for
    > the price)
    > is that it doesn't see Linux partitions (not to mention that it
    > doesn't run
    > on Linux)which makes them liable to potential attack. It looks like
    > for now
    > only Windows operationg system may be securely locked unless you run
    > Linux
    > as a VMware guest system on the DriveCrypted Windows host. I wonder
    > what are
    > your experiences with respect to securing the stand alone box with
    > uncontrolled physical access, like at the University (my case).
    > P.S. Have just noticed free stuff called CompuSec PC Security Suite
    > which
    > seems both Windows and Linux compatible though as compared to
    > DriveCrypt it
    > uses weaker encrypting algorithm AES-128 and looks like is much
    > slower. I
    > cannot wait to hear your comments.
    > Kindest regards,
    > --
    > Ricardo
    >



    Explain how encrypting your hard drive using an MBR bootstrap program
    replacement will protect the OS and any files. It doesn't. The
    purpose of boot-time encryption is to prevent someone from *stealing*
    the information from the hard drive. Once you boot past the
    encryption authentication, obviously the OS must be usable to the user
    which means files can be written. Once you're in, you're in and can
    modify the files. The purpose is not to let in a thief in the first
    place.
    Vanguard, Sep 25, 2006
    #2
    1. Advertising

  3. Ricardo

    nemo_outis Guest

    "Ricardo" <> wrote in
    news:c6eac$4516d82a$57cf8a7f$:

    > Hello,
    > I have just come to the conclusion that the only way to protect the
    > machine with free physical access to anauthorized personnel is... to
    > encrypt it. Unfortunately it seems that this can be done only the
    > lonely by DriveCrypt software which costs a lot. It's wonderful stuff
    > indeed allowing to encrypt the drive with authentication feature at
    > the pre-boot level! The encryption seems excellent AES-256 algotithm.
    > It's only drawback (except for the price) is that it doesn't see Linux
    > partitions (not to mention that it doesn't run on Linux)which makes
    > them liable to potential attack. It looks like for now only Windows
    > operationg system may be securely locked unless you run Linux as a
    > VMware guest system on the DriveCrypted Windows host. I wonder what
    > are your experiences with respect to securing the stand alone box with
    > uncontrolled physical access, like at the University (my case).
    > P.S. Have just noticed free stuff called CompuSec PC Security Suite
    > which seems both Windows and Linux compatible though as compared to
    > DriveCrypt it uses weaker encrypting algorithm AES-128 and looks like
    > is much slower. I cannot wait to hear your comments.
    > Kindest regards,



    Free Compusec works fine and is not discenibly slower than any other full
    HD OTFE encryption product (the hit from any of them is negligible on a
    fast machine).

    I wouldn't worry about AES-128, it's more than strong enough. In fact, it
    is rare for a user to have a password/passphrase that comes anywhere close
    to 128-bit equivalence - the password, not the encryption, is usually the
    weakest link.

    Regards,
    nemo_outis, Sep 25, 2006
    #3
  4. Ricardo

    Saqib Ali Guest

    Ricardo,

    There are a dozen or so full/whole disc encryption solutions available
    with pre-boot authentication option. See the URL below for list:

    http://www.full-disc-encryption.com/Full_Disc_Encryption.html

    I use CompuSec. It is free and has support for Linux. It has pre-boot
    authentication and has a builting credential manager. One thing that is
    missing support for Trusted Platform Module (TPM). TPM can make the key
    recovery possible and simplify single sign on.

    You might also want to take a look at hardware based Full Disc
    Encryption. There are few vendors that provide that. The above URL
    lists a few. Hardware based FDE works regardless of the OS you are
    using.

    If you are using a notebook Ce-Infosys has PCMCIA card or Seagate
    Technology will soon have FDE HDD for notebooks:
    http://www.seagate.com/docs/pdf/marketing/po_momentus_5400_fde_bb.pdf

    Also check out the Wikipedia article about Full Disc Encryption:
    http://en.wikipedia.org/wiki/FDE
    It talks about "Full disk encryption vs. file or directory encryption"

    P.S. If you have any feedback about DriveCrypt, please do send it to
    me. I am looking to buy that product as well.


    Ricardo wrote:
    > Hello,
    > I have just come to the conclusion that the only way to protect the machine
    > with free physical access to anauthorized personnel is... to encrypt it.
    > Unfortunately it seems that this can be done only the lonely by DriveCrypt
    > software which costs a lot. It's wonderful stuff indeed allowing to encrypt
    > the drive with authentication feature at the pre-boot level! The encryption
    > seems excellent AES-256 algotithm. It's only drawback (except for the price)
    > is that it doesn't see Linux partitions (not to mention that it doesn't run
    > on Linux)which makes them liable to potential attack. It looks like for now
    > only Windows operationg system may be securely locked unless you run Linux
    > as a VMware guest system on the DriveCrypted Windows host. I wonder what are
    > your experiences with respect to securing the stand alone box with
    > uncontrolled physical access, like at the University (my case).
    > P.S. Have just noticed free stuff called CompuSec PC Security Suite which
    > seems both Windows and Linux compatible though as compared to DriveCrypt it
    > uses weaker encrypting algorithm AES-128 and looks like is much slower. I
    > cannot wait to hear your comments.
    > Kindest regards,
    > --
    > Ricardo
    Saqib Ali, Sep 25, 2006
    #4
  5. Ricardo

    Anonyma Guest

    Vanguard wrote:

    > Explain how encrypting your hard drive using an MBR bootstrap program
    > replacement will protect the OS and any files. It doesn't. The


    Sure it does. By encrypting them.

    > purpose of boot-time encryption is to prevent someone from *stealing*
    > the information from the hard drive. Once you boot past the
    > encryption authentication, obviously the OS must be usable to the user


    Where in the poster's question did you see anything that would indicate
    he was wanting to do anything else? In fact the notable mention of wide
    open physical access more or less tells us he's trying to secure a
    machine that might be stolen or tampered with while he's not around,
    and the machine is off.

    > which means files can be written. Once you're in, you're in and can
    > modify the files. The purpose is not to let in a thief in the first
    > place.


    Yeah. That's the whole idea behind whole disk encryption. To keep
    people with physical access from "getting in in the first place". And
    it's the best protection there is in this scenario.
    Anonyma, Sep 25, 2006
    #5
  6. Ricardo

    Ricardo Guest

    U¿ytkownik "Ricardo" <> napisa³ w wiadomo¶ci
    news:c6eac$4516d82a$57cf8a7f$...
    > ...

    Thank you guys so much for your comments. They will help a lot.
    Kindest regards,
    Ricardo
    Ricardo, Sep 25, 2006
    #6
  7. Ricardo

    Vanguard Guest

    "Anonyma" <> wrote in message
    news:...
    > Vanguard wrote:
    >
    >> Explain how encrypting your hard drive using an MBR bootstrap
    >> program
    >> replacement will protect the OS and any files. It doesn't. The

    >
    > Sure it does. By encrypting them.
    >
    >> purpose of boot-time encryption is to prevent someone from
    >> *stealing*
    >> the information from the hard drive. Once you boot past the
    >> encryption authentication, obviously the OS must be usable to the
    >> user

    >
    > Where in the poster's question did you see anything that would
    > indicate
    > he was wanting to do anything else? In fact the notable mention of
    > wide
    > open physical access more or less tells us he's trying to secure a
    > machine that might be stolen or tampered with while he's not around,
    > and the machine is off.
    >
    >> which means files can be written. Once you're in, you're in and
    >> can
    >> modify the files. The purpose is not to let in a thief in the
    >> first
    >> place.

    >
    > Yeah. That's the whole idea behind whole disk encryption. To keep
    > people with physical access from "getting in in the first place".
    > And
    > it's the best protection there is in this scenario.
    >



    The subject says the OP is trying to protect the operating system.
    Excuse me, but why does the OP care since anyone can purchase or
    obtain a copy of the OS? I read "free physical access to anauthorized
    personnel" meaning the malcontents actually have *access* to the OS or
    data files, not simply that they can manage to leave a fingerprint on
    the case. The OP could use a BIOS password and padlock the case (to
    protect the BIOS settings, and some laptops don't even need to protect
    against physical entry) if that's all he wanted to do to restrict
    physical access *inside* the box (and not preventing instrusion means
    I can get around your encryption by altering the hardware inside by
    letting it read the unencrypted data after the cold file system has
    been decrypted after boot).

    It doesn't sound like the OP was particularly concerned about losing
    his laptop/desktop when travelling but protecting his *data* wherever
    he happens to leave the computer lying around. Well, why couldn't
    someone then load their own MBR bootstrap program that moves out the
    original one (used for security)? That is, they simply chain the
    original bootstrap program onto their own (by, perhaps, moving the
    original MBR bootstrap program into the rest of the unused first
    track). While the malware that runs under the OS can't get at the
    bootstrap password to decrypt the hard drive, the replacement MBR
    bootstrap can. If you want real security, you need to have it BEFORE
    you or the BIOS even touch the hard drive (or any other drive or
    storage device). Does CompuSec or DriveCrypt protect against the MBR
    bootstrap area getting usurped (just like they usurped it) and getting
    chained so the authentication used for decryption cannot be captured?
    Obviously if physically access isn't restricted than something could
    be installed inside the box that runs even before the MBR bootstrap
    program gets loaded.

    There is no point in protecting the OS from theft as it is readily
    available elsewhere. There is no point in protecting the applications
    (unless they are your projects). Both can be readily obtained
    elsewhere than from your piddly laptop so encrypting them is just
    stupid because it is a waste of performance. If the OP really means
    that they want to hide their data by encrypting it, then TrueCrypt
    would be sufficient, and it's free. Why incur the performance penalty
    of decryption on the OS when its just the data files that need to be
    protected? Plus you're not screwed over by the security product
    usurping the MBR bootstrap program that perhaps you would like to use
    for a multiboot manager. As I recall, Safeboot was the only one that
    would chain the original MBR bootstrap program after it usurped that
    spot while all the others simply step atop the MBR bootstrap area.
    Vanguard, Sep 26, 2006
    #7
  8. Ricardo

    TwistyCreek Guest

    Vanguard wrote:

    > "Anonyma" <> wrote in message
    > news:...
    > > Vanguard wrote:
    > >
    > >> Explain how encrypting your hard drive using an MBR bootstrap
    > >> program
    > >> replacement will protect the OS and any files. It doesn't. The

    > >
    > > Sure it does. By encrypting them.
    > >
    > >> purpose of boot-time encryption is to prevent someone from
    > >> *stealing*
    > >> the information from the hard drive. Once you boot past the
    > >> encryption authentication, obviously the OS must be usable to the
    > >> user

    > >
    > > Where in the poster's question did you see anything that would
    > > indicate
    > > he was wanting to do anything else? In fact the notable mention of
    > > wide
    > > open physical access more or less tells us he's trying to secure a
    > > machine that might be stolen or tampered with while he's not around,
    > > and the machine is off.
    > >
    > >> which means files can be written. Once you're in, you're in and
    > >> can
    > >> modify the files. The purpose is not to let in a thief in the
    > >> first
    > >> place.

    > >
    > > Yeah. That's the whole idea behind whole disk encryption. To keep
    > > people with physical access from "getting in in the first place".
    > > And
    > > it's the best protection there is in this scenario.
    > >

    >
    >
    > The subject says the OP is trying to protect the operating system.
    > Excuse me, but why does the OP care since anyone can purchase or
    > obtain a copy of the OS?


    Why would you believe "stealing" the operating system is the only
    threat. Far more likely scenario is wanting to keep people from
    tampering with the copy you have installed. A good way to do that is to
    prevent anyone from accessing it when nobody is around. Make it
    impossible to even boot the machine, or access the drive with the OS on
    it. Whole disk encryption is the best way to do that.

    > I read "free physical access to anauthorized
    > personnel" meaning the malcontents actually have *access* to the OS or
    > data files,


    Then you're misreading things or assuming way too much. Physical access
    means just that. They have the ability to lay hands on the equipment.
    It doesn't mean a single thing about access to data, you're just
    assuming the equipment is left on 24/7.

    > It doesn't sound like the OP was particularly concerned about losing
    > his laptop/desktop when travelling but protecting his *data* wherever


    Yes. And encrypting it is the best way to do that outside a hardened
    bunker and armed guards. In many ways it's more secure than even that.

    > he happens to leave the computer lying around. Well, why couldn't
    > someone then load their own MBR bootstrap program that moves out the
    > original one (used for security)? That is, they simply chain the


    Because the whole disk is encrypted. Replacing the MBR just makes the
    whole drive inaccessible even *with* proper authentication.

    Did you really believe that whole disk encryption could be circumvented
    by swapping MBR's, or maybe booting from another device??

    Wow...
    TwistyCreek, Sep 26, 2006
    #8
  9. Anonyma wrote:

    > Vanguard wrote:
    >
    >> Explain how encrypting your hard drive using an MBR bootstrap program
    >> replacement will protect the OS and any files. It doesn't. The

    >
    > Sure it does. By encrypting them.


    No, it doesn't. I can simply overwrite the hard drive with garbage and all
    files are gone.

    >> purpose of boot-time encryption is to prevent someone from *stealing*
    >> the information from the hard drive. Once you boot past the
    >> encryption authentication, obviously the OS must be usable to the user

    >
    > Where in the poster's question did you see anything that would indicate
    > he was wanting to do anything else? In fact the notable mention of wide
    > open physical access more or less tells us he's trying to secure a
    > machine that might be stolen or tampered with while he's not around,
    > and the machine is off.


    A non-tamper-resistent machine is trivially tampered to reveal everything.
    The simplest and most obvious method is to modify the bootloader to store
    the entered key additionally to its normal functions - that's why you
    should keep on a separate media. Then, ranging from modifying the BIOS
    (pretty easy) to reading data directly from RAM (FireWire, PCI, PCMCIA) and
    keyloggers (put between your keyboard and the keyboard connector) up to
    directly updating the CPU's microcode, everything else will be successful.

    >> which means files can be written. Once you're in, you're in and can
    >> modify the files. The purpose is not to let in a thief in the first
    >> place.

    >
    > Yeah. That's the whole idea behind whole disk encryption. To keep
    > people with physical access from "getting in in the first place". And
    > it's the best protection there is in this scenario.


    Beside that, what exactly would someone try if the OS boots without
    invention to a login screen where the password is unknown? I can't see how
    someone should be able to write files at this point.
    Sebastian Gottschalk, Sep 26, 2006
    #9
  10. Ricardo

    Nomen Nescio Guest

    Sebastian Gottschalk wrote:

    > Anonyma wrote:
    >
    > > Vanguard wrote:
    > >
    > >> Explain how encrypting your hard drive using an MBR bootstrap program
    > >> replacement will protect the OS and any files. It doesn't. The

    > >
    > > Sure it does. By encrypting them.

    >
    > No, it doesn't. I can simply overwrite the hard drive with garbage and all
    > files are gone.


    What a meaningless drizel of semantic idiocy... "a watermelon can't fly
    an airplane so it's no good for painting your house...".

    Oh, and you're replying to posters you've claimed to have killfiled
    again ya' pathetic loser.

    <rest snipped unread>
    Nomen Nescio, Sep 26, 2006
    #10
  11. Ricardo

    Vanguard Guest

    "TwistyCreek" <> wrote in message
    news:...

    > Why would you believe "stealing" the operating system is the only
    > threat. Far more likely scenario is wanting to keep people from
    > tampering with the copy you have installed.


    You don't need encryption to restore to a known state for the OS. You
    don't need encryption to keep out the abusers in the first place.

    > Make it
    > impossible to even boot the machine, or access the drive with the OS
    > on
    > it. Whole disk encryption is the best way to do that.


    No, preventing it back in the hardware is the best way to prevent
    unauthorized use or access.

    >> he happens to leave the computer lying around. Well, why couldn't
    >> someone then load their own MBR bootstrap program that moves out
    >> the
    >> original one (used for security)? That is, they simply chain the

    >
    > Because the whole disk is encrypted. Replacing the MBR just makes
    > the
    > whole drive inaccessible even *with* proper authentication.


    *Replacing* the MBR bootstrap program (for the security program) would
    not even propose authentication nor would it interfere with the
    authentication in the *chained* bootstrap program. I was talking
    about *chaining* their MBR bootstrap program *after* yours. Just like
    how they usurped the MBR is also how you can usurp it and move theirs
    somewhere else to run it *after* yours runs first. The MBR is not
    protected by the hardware if you permit physical access inside the
    computer. If you let me have physical access, I can move out your old
    MBR bootstrap program, insert my own in the MBR, and mine would
    execute FIRST and then run yours.

    Okay, if you don't understand chaining of MBR bootstrap programs, just
    think of me inserting a boot virus (in the MBR and not in the boot
    sector of a partition for the OS in that partition).

    > Did you really believe that whole disk encryption could be
    > circumvented
    > by swapping MBR's, or maybe booting from another device??


    Yes, bootstrap programs can be moved to alternate locations and
    another bootstrap program ran FIRST which then chains to the wherever
    the original one got moved. The MBR is not protected if physical
    access is not protected.

    There is only one reason to encrypt the partition containing the OS:
    you are too lazy or ignorant of where are the user profiles, how to
    move them, how to designate in which partitions are the swap files (if
    you really think that 4K fragments of your data is serious exposure),
    TIF, favorites, and so on. About the only data that I haven't moved
    to my 2nd drive (so I can reinstall a fresh copy of the OS in its
    partition and then tweak it to point again at all my saved data on the
    2nd drive) is the pagefile (not hard to do, though) and the .dat files
    for the user registry (but I suspect they'd work just fine once I make
    the registry edits to move my profile to the 2nd drive). Yeah, it
    takes work to setup the OS so its partition is polluted with your
    sensitive data but I'd rather do that then incur the performance
    penalty of having to decrypt the OS partition. For all the money that
    I spend to gain more performance from my system, I'm certainly not
    going to use some software-based encryption scheme to obviate a
    portion of those performance costs.
    Vanguard, Sep 28, 2006
    #11
  12. Ricardo

    Anonyma Guest

    Vanguard wrote:

    > "TwistyCreek" <> wrote in message
    > news:...
    >
    > > Why would you believe "stealing" the operating system is the only
    > > threat. Far more likely scenario is wanting to keep people from
    > > tampering with the copy you have installed.

    >
    > You don't need encryption to restore to a known state for the OS. You
    > don't need encryption to keep out the abusers in the first place.


    You're making no sense at all. Juxtaposing unrelated ideas over top of
    one another. What you "need" is whatever best fits your needs, and in
    this case it's obviously an encrypted drive.

    > > Make it
    > > impossible to even boot the machine, or access the drive with the OS
    > > on
    > > it. Whole disk encryption is the best way to do that.

    >
    > No, preventing it back in the hardware is the best way to prevent
    > unauthorized use or access.


    Totally irrelevant. Please review the thread, especially the original
    post where it was clearly stated this isn't possible. You might want to
    bring yourself up to speed on the "hardened bunker" comment that was
    made while you're at it too.

    > >> he happens to leave the computer lying around. Well, why couldn't
    > >> someone then load their own MBR bootstrap program that moves out
    > >> the
    > >> original one (used for security)? That is, they simply chain the

    > >
    > > Because the whole disk is encrypted. Replacing the MBR just makes
    > > the
    > > whole drive inaccessible even *with* proper authentication.

    >
    > *Replacing* the MBR bootstrap program (for the security program) would
    > not even propose authentication nor would it interfere with the
    > authentication in the *chained* bootstrap program. I was talking
    > about *chaining* their MBR bootstrap program *after* yours. Just like
    > how they usurped the MBR is also how you can usurp it and move theirs


    Meaningless nonsense. No matter what you "chain" or replace the data is
    encrypted. Period. The only way to circumvent that is to have the
    keys/passwords or defy all known laws of mathematics. So unless your
    "chained" bootstrap code startswith(psychicpowers) you're SOL.

    > somewhere else to run it *after* yours runs first. The MBR is not
    > protected by the hardware if you permit physical access inside the
    > computer. If you let me have physical access, I can move out your old


    Again, you missed to boat completely here. The problem at hand is how
    to best secure a machine where some number of people other than the
    "owner" have physical access.

    > MBR bootstrap program, insert my own in the MBR, and mine would
    > execute FIRST and then run yours.


    So what? You've gained exactly squat.

    > There is only one reason to encrypt the partition containing the OS:
    > you are too lazy or ignorant of where are the user profiles, how to


    User profiles??

    Oh brother..... <laugh>
    Anonyma, Sep 28, 2006
    #12
  13. Anonyma wrote:

    >> No, preventing it back in the hardware is the best way to prevent
    >> unauthorized use or access.

    >
    > Totally irrelevant. Please review the thread, especially the original
    > post where it was clearly stated this isn't possible. You might want to
    > bring yourself up to speed on the "hardened bunker" comment that was
    > made while you're at it too.


    A simpler locker at the case is most likely sufficient.

    >> *Replacing* the MBR bootstrap program (for the security program) would
    >> not even propose authentication nor would it interfere with the
    >> authentication in the *chained* bootstrap program. I was talking
    >> about *chaining* their MBR bootstrap program *after* yours. Just like
    >> how they usurped the MBR is also how you can usurp it and move theirs

    >
    > Meaningless nonsense. No matter what you "chain" or replace the data is
    > encrypted. Period. The only way to circumvent that is to have the
    > keys/passwords or defy all known laws of mathematics. So unless your
    > "chained" bootstrap code startswith(psychicpowers) you're SOL.


    No, you really don't get it.

    1. I seize your hardware
    2. I replace the MBR with my own, which does exactly the same as the
    original one plus additionally stores the entered password somewhere
    3. I put the machine back where it was
    4. you boot it up, you enter the password as usual to get access to your
    data
    5. I seize your hardware again, read the stored password, enter it, et
    voilà

    This works because the MBR is neither encrypted nor authenticated, and
    because you cannot reasonably detect any modification.

    The solution is to store the MBR and its chained programs on a separate
    removable media (floppy disc, CD-ROM, SD/CF-card) and only boot from there.

    >> somewhere else to run it *after* yours runs first. The MBR is not
    >> protected by the hardware if you permit physical access inside the
    >> computer. If you let me have physical access, I can move out your old

    >
    > Again, you missed to boat completely here. The problem at hand is how
    > to best secure a machine where some number of people other than the
    > "owner" have physical access.


    Not at all, at least not until you can detect any physical modification.
    Even when ensuring to not run any untrusted code as described above,
    attaching malicious hardware that intercepts keystrokes or has direct
    access to main memory is pretty hard to notice.
    Sebastian Gottschalk, Sep 28, 2006
    #13
  14. Sebastian Gottschalk wrote:

    > No, you really don't get it.


    Don't think so? Here's how the OP started this thread...

    "I have just come to the conclusion that the only way to protect the
    machine with free physical access is..."

    If you're having trouble with the meaning of "free physical access"
    bitch at whatever third world educational system it was that let you
    remain functionally illiterate, and spend half your monthly McDonald's
    wages on a pocket dictionary.

    Is that clear enough for ya' there skippy?

    <snip juvenile reiteration of the obvious, but irrelevant>
    Borked Pseudo Mailed, Sep 28, 2006
    #14
  15. Ricardo

    nemo_outis Guest

    > Yes, bootstrap programs can be moved to alternate locations and
    > another bootstrap program ran FIRST which then chains to the wherever
    > the original one got moved. The MBR is not protected if physical
    > access is not protected.


    Yes, this can be done, but:

    1. it is not quite as straightforward as you make out

    2. it is easily thwarted.

    Regarding point 1, it takes a fair level of technical skill to write one's
    own MBR to splice into the chain. Moreover, unless the modified MBR can do
    wnhat it wishes *as well as return control to the original encrypted boot
    process* all within one track, then it will have to put its malware
    elsewhere on the HD. And there our malefactor has a bit of a problem:
    there's no place to put it without risking trashing some encrypted file on
    the HD (Yes, the malefactor can just "roll the dice" that he will not trash
    a file, not trash an important file, or the mess will not be noticed, but
    that is hardly an - ahem! - elegant solution.

    Regarding point 2, it is very easy to boot up from, say, a known good read-
    only CD and verify the MBR (or even just overwrite it). Then one would boot
    again, this time from the encrypted HD.

    Much easier and faster than verifying the state of the entire HD. This
    two-stage boot is seldom done, I agree, but that's because the risk of MBR
    tampering is largely a theoretical one that is strongly discounted in most
    folks' threat model.

    Regards,
    nemo_outis, Sep 28, 2006
    #15
  16. nemo_outis wrote:

    >> Yes, bootstrap programs can be moved to alternate locations and
    >> another bootstrap program ran FIRST which then chains to the wherever
    >> the original one got moved. The MBR is not protected if physical
    >> access is not protected.

    >
    > Yes, this can be done, but:
    >
    > 1. it is not quite as straightforward as you make out
    >
    > 2. it is easily thwarted.
    >
    > Regarding point 1, it takes a fair level of technical skill to write one's
    > own MBR to splice into the chain.


    No, it's trivial.

    > Moreover, unless the modified MBR can do
    > wnhat it wishes *as well as return control to the original encrypted boot
    > process* all within one track, then it will have to put its malware
    > elsewhere on the HD.


    You just need one little modification of the original boot program, that is
    to store the entered password or the derived key somewhere. Just due to the
    512 Byte alignment, you usually already have enough space available. And
    what about optimizing the original program to reduce its size? Trivial.

    > And there our malefactor has a bit of a problem:
    > there's no place to put it without risking trashing some encrypted file on
    > the HD


    If one would actually need to do so, who cares? One cluster is enough, and
    the chance of critically damaging a critical system file is so low.

    And if you really care, why don't you modify the BIOS instead?

    > Regarding point 2, it is very easy to boot up from, say, a known good read-
    > only CD and verify the MBR (or even just overwrite it). Then one would boot
    > again, this time from the encrypted HD.


    What about simply booting from this CD? And yes, you stated the common
    solution to at least this problem.

    > Much easier and faster than verifying the state of the entire HD. This
    > two-stage boot is seldom done, I agree, but that's because the risk of MBR
    > tampering is largely a theoretical one that is strongly discounted in most
    > folks' threat model.


    What a bullshit.
    Sebastian Gottschalk, Sep 28, 2006
    #16
  17. Ricardo

    Ricardo Guest

    U¿ytkownik "nemo_outis" <> napisa³ w wiadomo¶ci
    news:Xns984C53303B13Babcxyzcom@127.0.0.1...
    >> Yes, bootstrap programs can be moved to alternate locations and
    >> another bootstrap program ran FIRST which then chains to the wherever
    >> the original one got moved. The MBR is not protected if physical
    >> access is not protected.

    >
    > Yes, this can be done, but:
    >
    > 1. it is not quite as straightforward as you make out
    >
    > 2. it is easily thwarted.
    >
    > ...
    > Regarding point 2, it is very easy to boot up from, say, a known good
    > read-
    > only CD and verify the MBR (or even just overwrite it). Then one would
    > boot
    > again, this time from the encrypted HD.

    What kind of software would you suggest for preparation and usage of such a
    CD? Maybe a user-friendly tutorial coming with it? :) I have never played
    with hard disk at such low level and I can imagine that it's very
    dangerous...

    > Much easier and faster than verifying the state of the entire HD.

    What do you mean by that? Calculating the control sum of the encrypted
    partition or something? It may be difficult in the case of the one with
    operating system as the size and number of files do change so often, don't
    they?

    > This
    > two-stage boot is seldom done, I agree, but that's because the risk of MBR
    > tampering is largely a theoretical one that is strongly discounted in most
    > folks' threat model.

    Thank you so much for your interesting comments!
    Kindest regards,
    Ricardo
    Ricardo, Sep 28, 2006
    #17
  18. Ricardo wrote:

    >> Regarding point 2, it is very easy to boot up from, say, a known good
    >> read-only CD and verify the MBR (or even just overwrite it). Then one would
    >> boot again, this time from the encrypted HD.

    > What kind of software would you suggest for preparation and usage of such a
    > CD? Maybe a user-friendly tutorial coming with it? :) I have never played
    > with hard disk at such low level and I can imagine that it's very
    > dangerous...


    Is 'dd if=/dev/hdXY bs=512 count=Z | sha1sum' really that hard? Anyway, the
    FDE software should already offer such an option.
    Sebastian Gottschalk, Sep 28, 2006
    #18
  19. Ricardo

    nemo_outis Guest

    "Ricardo" <> wrote in
    news:10292$451be220$57cf8a7f$:

    > U¿ytkownik "nemo_outis" <> napisa³ w wiadomo¶ci
    > news:Xns984C53303B13Babcxyzcom@127.0.0.1...
    >>> Yes, bootstrap programs can be moved to alternate locations and
    >>> another bootstrap program ran FIRST which then chains to the
    >>> wherever the original one got moved. The MBR is not protected if
    >>> physical access is not protected.

    >>
    >> Yes, this can be done, but:
    >>
    >> 1. it is not quite as straightforward as you make out
    >>
    >> 2. it is easily thwarted.
    >>
    >> ...
    >> Regarding point 2, it is very easy to boot up from, say, a known good
    >> read-
    >> only CD and verify the MBR (or even just overwrite it). Then one
    >> would boot
    >> again, this time from the encrypted HD.

    > What kind of software would you suggest for preparation and usage of
    > such a CD? Maybe a user-friendly tutorial coming with it? :) I have
    > never played with hard disk at such low level and I can imagine that
    > it's very dangerous...



    The program I've used in the past to backup/restore the MBR (all of track
    0 actually) is called Diskpatch (just because I happened to have a copy
    of it and knew it would do the trick). It's not free, however. But I
    would imagine a little looking would find a zillion such programs, many
    of them free.

    Back then I did my backups/restores of the MBR from floppies under DOS
    (How quaintly antique! I can hear you say). If you want to do it from CD
    you'll need an autorun CD The eponymous AutoRun program is the one I've
    used (in a variety of contexts, not just MBR backup/restore) to make
    bootable CDs (again, because I happened to have it), but there are
    undoubtedly others, some free. Or you could jack around and cobble
    together a way to do this process from a USB stick.

    As for any of this being dangerous to the health of your data on the HD
    if you bugger things up - you're damned right it is!

    And that's why you should make a full image backup of your drive before
    you start (using Ghost, Acronis, etc.) including - and this step is too
    often skipped - confirming that the backup can be restored! If you
    aren't already in the habit of making regular backups now's the time to
    acquire it.

    With a rock-solid confirmed-restorable backup on hand you can then mess
    with MBRs, etc. to your hearts content.

    Only once you've got this drill down for an unencrypted drive should you
    encrypt the entire HD and play with backing up and restoring the MBR for
    the encrypted case (if everything goes horribly wrong you will simply
    restore the unencrypted backup you made earlier).


    >> Much easier and faster than verifying the state of the entire HD.

    > What do you mean by that? Calculating the control sum of the encrypted
    > partition or something? It may be difficult in the case of the one
    > with operating system as the size and number of files do change so
    > often, don't they?


    Well,what you might want to do is ensure that the "state" of the disk
    (the contents of MBR, files, metadata, etc.) has not changed. This could
    be desired even for an unencrypted drive.

    And one way you could do it is to take the hash (using MD5, SHA-1, or
    even better, some of the stronger hashes like SHA 256, RIPEMD, Whirlpool,
    etc.) of every file on the drive (or every sector) and then later when
    you come back to use the computer again, confirm that no files (sectors)
    have changed by again taking the hashes. This process is, however, so
    slow and tedious that no one would have the patience and discipline to
    keep doing it.

    Which is why instead I would suggest using a fully-encrypted drive and
    only having to check (or as I describe above, simply overwrite) the only
    tiny unprotected part, the MBR and Track 0.

    Regards,
    nemo_outis, Sep 28, 2006
    #19
  20. Ricardo

    nemo_outis Guest

    Sebastian Gottschalk <> wrote in
    news::

    > nemo_outis wrote:
    >
    >> Regarding point 1, it takes a fair level of technical skill to write
    >> one's own MBR to splice into the chain.

    >
    > No, it's trivial.


    Thank you for putting that asinine comment so early in your reply - it
    saved me from bothering to read the rest of the bullshit you wrote.

    Regards,
    nemo_outis, Sep 28, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. naderbd
    Replies:
    1
    Views:
    552
    Frank
    Jul 29, 2005
  2. Rich
    Replies:
    7
    Views:
    371
    Simon Kellett
    Nov 16, 2004
  3. Consultant

    Re: 32 bit operating system

    Consultant, Jan 8, 2004, in forum: MCSE
    Replies:
    0
    Views:
    485
    Consultant
    Jan 8, 2004
  4. Politician Spock

    Re: 32 bit operating system

    Politician Spock, Jan 8, 2004, in forum: MCSE
    Replies:
    0
    Views:
    410
    Politician Spock
    Jan 8, 2004
  5. Scorpio

    Operating System Not Found

    Scorpio, Jun 29, 2003, in forum: Computer Support
    Replies:
    13
    Views:
    1,515
    Donald Link
    Jul 2, 2003
Loading...

Share This Page