An OS security question

[ManOfSteel]

Hello,
When I will be making my OS secure, I will add to it an identification routine that will run rigth after the boot sequence and will ask for a user name and password.
Now, in this routine there will be, let's say, some instructions that will take the password from the user, pass it through a hash function, compare it to the stored encrypted passwords and finaly show an error message or allow access.
So, what will prevent a malicious user to modify the conditional jump in this routine so that it sees no difference between the right and the wrong password, in the same way some software serial-protections are cracked? How do OSes like Linux handle this?
I would like to have your ideas/suggestions about this.
Thanks for any help

[zloba]

So, what will prevent a malicious user to modify the conditional jump in this routine so that it sees no difference between the right and the wrong password, in the same way some software serial-protections are cracked?

how whould the malicious user get a chance to modify your system's code to start with? what kind of malicious user do you mean - the system's owner, an outsider with unprivileged login access, someone who stole a hard drive or the whole box?

How do OSes like Linux handle this?

if you mean preventing a legitimate user in control of the system from cracking their own system (such as disabling a cdkey and passing it to warez dudes) - with linux being free to distribute and modify, this is a non-issue. imagine "bootleg copies of Linux"
if you mean something else, explain exactly what.

[Candy]

if the system cannot prevent access to those files before the loading of the OS, the user is fucked anyway. You could use a one-type of hash for checking and a different one for decoding a file, that might work.

user enters password A, hashed using H1 to B, using H2 to C. B is compared to stored password. If matches, C is used as key to decrypt file S(user), which is K symetrically encrypted with C beforehand. The result of this decryption will be system key K.

The weak point here probably is when a user has an easy password, allowing access to the system for all users. Of course, extend this for user files using H3 for D, to decript U(user) for UK(user), using that for his own files.

Of course, this is all quite hypothetical. If you can't logically shut off non-your-HD access or don't weld up your box you don't need software security.

This would prevent user file hijack though...

[Solar]

As much as I despise it, TCPA might have the answer.

The concept is to encrypt files in a way that they cannot be read by any other system but the authorized OS running on this specific boxen.

The problem with the whole system is that embracing it means handing all keys to the system to those in power, and not keeping copies for yourself - metaphorically speaking. The architecture would be a nice thing indeed if it weren't for the usual suspects (Microsoft, Intel) pulling the reins.

[Candy]

The concept is to encrypt files in a way that they cannot be read by any other system but the authorized OS running on this specific boxen.

The concept behind good platforms being broken is that when they're used they generate a LOT of test material for people to crack. You only have to crack one.

If you have a known plaintext attack on a known algorithm, you can damn well bruteforce the keys. There is no way you can keep those keys secret. If you have an attack against an unknown algorithm, you can of course try to derive the algorithm or just hack the box (using tools such as a welding iron, to unweld the TCPA BIOS chip) and then read it out manually. XBOX etc have modchips for the exact same purpose. The TCPA idea isn't only flawed, it's unworkable.

[Dreamsmith]

There is not now, nor has there ever been, nor will there ever be, a way to secure a machine from someone who has physical access to the hardware. TCPA, just like all forms of copy protection, throws up barriers that hinder casual users and line the pockets of their developers who sell it to gullible people looking to protect their IP, while doing nothing at all to prevent actual pirates or crackers from waltzing past the security measures and doing as they please.

It is impossible to secure anything from illegitimate access/use while continuing to allow legitimate use. This isn't an unsolved technical issue, it's simply not even theoretically possible.

That doesn't mean you can't make it more difficult. The whole security game is to not make things impossible, just to make them difficult enough that it's more trouble than it's worth. If it takes a $2 billion dollar computer to crack the encryption on your credit card with an $8000 spending limit, no one will bother (unless they have over 250 million of them to crack).

But I digress. With regards to the TCPA, the problem with anything of that sort is the same as with DVDs. In order to play a DVD, you have to give people all the tools they need to decrypt the data. Best you can do is try to obscure the information you've given them, but the fact of the matter is, if they can use it at all, you must have given them the keys.

So, when Solar says you have to hand the keys to those in power, he's told half the story. The problem for things like the TCPA is that, in order for it to work, they have to hand the keys back to you for you to be able to use your computer at all. This means they need to hand crackers the keys as well, and while an ordinary user may not be able to easily find the key, the crackers will do it in less than a week.

To make a long story short, the TCPA is a very complicated and technically challenging way to sell nervous IP holders some snake oil.

[Candy]

TCPA, just like all forms of copy protection, throws up barriers that hinder casual users and line the pockets of their developers who sell it to gullible people looking to protect their IP, while doing nothing at all to prevent actual pirates or crackers from waltzing past the security measures and doing as they please.

In the case of unlimited time, everything's possible. There's no protection you cannot crack given enough time.

For most forms however, there are easier ways. The protection scheme needs a "bypass" so the casual user spends microseconds, when giving a very simple short answer to a question (common question is, what is your password). The shorter the answer the shorter the "crackers" crack on the access.

The password-section on behalf of the user should be so complex that attempting all possible values, coming to the users answer, is longer than bruteforcing the access using a binary key. The user gives a key, with N bits of entropy. This can be expanded to T bits, with only N bits of entropy, or shrunk to C bits, with only C bits of entropy left. In short, the weakest link defines how hard it is.

The input has to be correct up to the lowest bit count of the entropy, because when shrunk more than one password creates the same bit sequence. One out of 2^bitcount is correct.

Calculating this value should be so hard that it's cheaper to use a different access route (or not to do it). For a criminal it means that using any possible way of cracking it should be much more expensive & complex than putting a gun to your head and demanding your password (including what will probably happen afterward). For corporations, it should be so computationally expensive that it's not worth trying to do it, IE, the power costs or time costs, or any other cost combined, exceeds the amount of profit they make.

For your own computer, the weakest link is always the part people exploit. If you seal up your OS completely, they rip out the harddisk and view it in some other OS. If you seal up the computer and make it dualbootable with DOS, they'll abuse the BIOS functions for access. Any way will do, the weakest part is the point


Back to the topic of computer security, if you want to completely secure the computer, make the end route hard. This is software, it's possible. Use a 4096-bit symmetric encryption on each sector, store the key in a different sector secured with a 4096 bit hash, and protect those hashes using your password (which needs at least 4096 bits of entropy, for the system to work). This comes down to a 1.3K password. Use a smartcard if you can't remember it

Then, your system is protected. Protect the access to the bootup code, that is, prevent BIOS access. Prevent access to the BIOS jumper, IE by removing it altogether, shorting the pins, something like that. Prevent removal of the battery. Prevent access to removal of the harddisk, that is, seal up your box really tight. Now, the barrier to access is physical (you need to get to the HD, and use it in a different computer) and logical (you need a compatible 4096 bit key for access). Without those two, there's no way they can get access.

PS: this assumes there are no backroads. You must keep using the 4096 bit key for all access, if even just for XOR. You must make all data look like random, never distribute a plain copy of the key, never put blank info on the disk, if possible, prevent any logic whatsoever. The attacker may not get any plain text, for a possible break on your key system.

And protect all source code, without algorithm it's even harder.



Conclusion: just make it hard. Not many people want what you have, and if they do, a gun to your head will make you give access to them.