Hi,
A stupid question for both Candy and Pype...
If I break into your computer room and steal your computer, what will prevent me from accessing all of your private files?
If your computer is running linux it'd take me 10 minutes with a boot CD to gain root access. I wouldn't even need to steal the computer if I can get access for long enough to FTP what I wanted elsewhere - you might not even find out I was ever there (think about disgruntled employees "working late" and selling hard earned data to a competing company).
If your computer is running any OS (and if a boot CD isn't an option) I can install that OS on another computer, plug your hard drives in and have access to all of your files that way.
If the file system stored a password, such that any OS that doesn't have the same password will refuse to mount the partition, then it would prevent this. In this case, if the OS is open source I'd need to download the OS's source code and make myself a hacked version - it'd add a few hours to the time I'd need to get access to all of your files. If the OS is closed source but uses an open file system specification, then I'd need to find the password on disk and adjust it.
Would you agree that closed source, proprietory file systems (e.g. protected via. "trade secrets") are the only way to prevent this (or at least make it much more difficult)?
Cheers,
Brendan
Filesystem for Brendan's OS
Filesystem for Brendan's OS
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:FileSystem...
No. I don't agree. The only to prevent this is to encrypt your data with a password that is not on the medium. There are several way to do this (e.g. only keeping self-encrypted password on the disk for verification purpose) ... If you're really paranoid, run your system in a faraday cage atop of a huge tower, isolated from any network connection ...Brendan wrote: Hi,
A stupid question for both Candy and Pype...
Would you agree that closed source, proprietory file systems (e.g. protected via. "trade secrets") are the only way to prevent this (or at least make it much more difficult)?
I have already recovered datas from a failed partition by grepping the content of /dev/hda1 for known patterns in the data.
Trade secrets are vulnerable to 'leaking' employees, social engineering, reverse engineering, backdoors and whatever ...
Re:FileSystem...
No, of course not. This is a discussion forum, not an agreement forum.Brendan wrote: Hi,
A stupid question for both Candy and Pype...
<lots of logical stuff that doesn't apply>
Would you agree that closed source, proprietory file systems (e.g. protected via. "trade secrets") are the only way to prevent this (or at least make it much more difficult)?
Content answer: No. I've explained how to before on this forum. The idea is to hash your password twice and to store the second hash verbatim. Encrypt files/directories with the first hash. Done.
If you don't have the password, you CAN NOT get to the files. You CAN NOT use my OS to gain access at all, since you can't even match the second hash. Even if you could, there's no guarantee that you have the right password in fact.
Put bluntly: If you were to make a computer that would do 1 billion hack attempts a second, you are going to need at least 2^226 seconds to make something that matches the second hash. You need another 2^256 tries until you can find something that also matches the first hash. Ergo, even if somebody makes superconductive high-speed parallel computing common, and the whole universe allows you to use their computing power, you would not be able to hack my files before I died.
That is, if my password is any good. You can count on me (being a nerd & all) to use a 34-character password for important files.
Re:FileSystem...
Pretty hard to fake actually... It's actually not pink paper at all, but the lines in darker pink on it are so fine that you can't distinguish them without a microscope. Then, it contains something like half a book in minuscule text, strips of aluminum foil embedded in it, two pieces of awkward plastic on it, stamps, special see-through stuff, perforated stuff, it lights up in UV light and probably shows something funny, stuff like that.bubach wrote: OT:Erm.. Do you use a paper as a drivers licence? In sweden thats only valid until you get the standard credit card-type (after a week or so, by mail), and it have always been like that..so my pink piece of paper is safe for now...
Can't be very secure? Or have i missed something?
Plus, getting the original costs you around 45 euros, so that's kind of cheaper than creating a hacked one.
Re:FileSystem...
Hi,
The only way I can see to avoid this is not storing the passwords anywhere, and asking the user for them during boot (but that's not an option for me).
BTW I'm not trying to antagonize here - my OS needs "enhanced" security because it's peer to peer distributed. Basically the same filesystem is spread across N computers (that may be anywhere in the world), which gives N points of vulnerability. It's not like a normal OS where you can lock the computer in a secured room.
What I'm looking for is a way to make this distributed file system secure, such that a hard drive can be taken from one node (or computer) and inserted into another node in the same cluster without effecting anything.
At the same time, if the hard drive is taken from one cluster to another cluster (or to any computer outside of the original cluster) all data must be unusable.
The peer to peer nature of it means that at any time any node/s may be inaccessible - a central password server running on a specific node won't work. This can be caused by turning computers off, hardware or software failure, or networking problems. For example, a cluster can consist of 100 computers on a LAN in America and 8 computers on a LAN in China where both LANs are connected via. internet tunnelling. The OS/cluster will remain usable if the internet connection breaks, with both halves of the cluster running independantly until the internet connection is re-established (even when different nodes on each LAN are being turned off and on at random times).
I can get the above situation to work without severely disrupting the users, but I haven't been able to think of a way to make this distributed file system secure enough without relying on "trade secrets" and closed source (and to be honest I'd rather a better method - disassembling is time consuming but not impossible).
If I can make this secure enough for government/military use the marketting possibilities would be much more to my liking
.
Cheers,
Brendan
Sure, but in order for the OS to be able to access the data it will need to store each file system's password somewhere and contain code to unlock and decrypt. Anyone could copy exactly what the OS does to access the data themselves (assuming they can find out what the OS does by reading and/or modifying the OS's source).Candy wrote:Content answer: No. I've explained how to before on this forum. The idea is to hash your password twice and to store the second hash verbatim. Encrypt files/directories with the first hash. Done.
The only way I can see to avoid this is not storing the passwords anywhere, and asking the user for them during boot (but that's not an option for me).
BTW I'm not trying to antagonize here - my OS needs "enhanced" security because it's peer to peer distributed. Basically the same filesystem is spread across N computers (that may be anywhere in the world), which gives N points of vulnerability. It's not like a normal OS where you can lock the computer in a secured room.
What I'm looking for is a way to make this distributed file system secure, such that a hard drive can be taken from one node (or computer) and inserted into another node in the same cluster without effecting anything.
At the same time, if the hard drive is taken from one cluster to another cluster (or to any computer outside of the original cluster) all data must be unusable.
The peer to peer nature of it means that at any time any node/s may be inaccessible - a central password server running on a specific node won't work. This can be caused by turning computers off, hardware or software failure, or networking problems. For example, a cluster can consist of 100 computers on a LAN in America and 8 computers on a LAN in China where both LANs are connected via. internet tunnelling. The OS/cluster will remain usable if the internet connection breaks, with both halves of the cluster running independantly until the internet connection is re-established (even when different nodes on each LAN are being turned off and on at random times).
I can get the above situation to work without severely disrupting the users, but I haven't been able to think of a way to make this distributed file system secure enough without relying on "trade secrets" and closed source (and to be honest I'd rather a better method - disassembling is time consuming but not impossible).
If I can make this secure enough for government/military use the marketting possibilities would be much more to my liking
.Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:FileSystem...
Why encrypt the OS files? They're pretty much free and open source, for all I care. You don't encrypt the obvious. That's just intentional slowing of your system.Brendan wrote: Hi,
Sure, but in order for the OS to be able to access the data it will need to store each file system's password somewhere and contain code to unlock and decrypt. Anyone could copy exactly what the OS does to access the data themselves (assuming they can find out what the OS does by reading and/or modifying the OS's source).Candy wrote:Content answer: No. I've explained how to before on this forum. The idea is to hash your password twice and to store the second hash verbatim. Encrypt files/directories with the first hash. Done.
Don't encrypt anything but user files. Ask the user for their password/code thingy/keycard upon login (at which time they pretty much need to use it anyway) and most of all, NEVER EVER EVER EVER EVER store the password in plain text or single-hash ANYWHERE. Only keep it in memory in single-hash.The only way I can see to avoid this is not storing the passwords anywhere, and asking the user for them during boot (but that's not an option for me).
That gives it another dimension, but if the others can treat it as a distributed block system, you can just plain ask for blocks and decrypt them yourself.BTW I'm not trying to antagonize here - my OS needs "enhanced" security because it's peer to peer distributed. Basically the same filesystem is spread across N computers (that may be anywhere in the world), which gives N points of vulnerability. It's not like a normal OS where you can lock the computer in a secured room.
Is possible using the group password feature in *FS. Explanation at the bottom.What I'm looking for is a way to make this distributed file system secure, such that a hard drive can be taken from one node (or computer) and inserted into another node in the same cluster without effecting anything.
At the same time, if the hard drive is taken from one cluster to another cluster (or to any computer outside of the original cluster) all data must be unusable.
*FS is pretty much all you want... Will explain all the details in the next post. This one is probably full.The peer to peer nature of it means that at any time any node/s may be inaccessible - a central password server running on a specific node won't work. This can be caused by turning computers off, hardware or software failure, or networking problems. For example, a cluster can consist of 100 computers on a LAN in America and 8 computers on a LAN in China where both LANs are connected via. internet tunnelling. The OS/cluster will remain usable if the internet connection breaks, with both halves of the cluster running independantly until the internet connection is re-established (even when different nodes on each LAN are being turned off and on at random times).
I can get the above situation to work without severely disrupting the users, but I haven't been able to think of a way to make this distributed file system secure enough without relying on "trade secrets" and closed source (and to be honest I'd rather a better method - disassembling is time consuming but not impossible).
If I can make this secure enough for government/military use the marketting possibilities would be much more to my liking
Re:Filesystem for Brendan's OS
OK, details for group password:
Each user has a password U1. It's hashed once to U2, and with a different hash to U3. U3 is also stored and compared for equality. If equal, U2 is used for decrypting (secret-key, undecided keysystem but probably AES or Serpent, depending on whether I can find any proof of AES being broken) his copy of the group password G1. The group password is then hashed once to G2 and used for decrypting all the files within the group (same encryption method). Hence, it doesn't matter which of the users in the group decrypts the file, they all use the same password and can still use private files. IE, the group policy implemented 100% securely. Note, each user must have his own distinguished login account (obviously). This moves the security problem back into the world us computer nerds escape and can't prevent from malfunctioning. The real world, that is. If you are being threatened you will give your password. If you're corrupt, there's no stopping you. The only danger / flaw that I can think of right now is that for changing the group password you need everybody in the group to be present, or to encrypt it using the old group password
Details for slice redundancy and independency:
Each slice encompasses the entire section directory table. This way, if you have but one slice you can still mount it and use whatever's available. Using reed-solomon coding it can be made redundant with the minimum of space used (not in mind-design yet, being put in there) yet providing redundancy. This way, with any given N nodes you can mount the fs and expect to be able to open a file, not saying much about performance (however, nowadays, if you're not running a 3d game in the background too you're probably wasting your processor). Thereby, if the files were encoded to require the minimum the network could support in terms of smallest sublan and encode each file with that as segments, and the available number of slices as total number, any subset will do. So, any sublan of required size will also work, and contain all files marked as such (FS level setting even, so that works pretty nicely). All that's undecided atm is whether it's read-only if not all the other slices are present, or that a log is kept with changes for the others. This is complex, since you can also get collisions and stuff like that.
Each user has a password U1. It's hashed once to U2, and with a different hash to U3. U3 is also stored and compared for equality. If equal, U2 is used for decrypting (secret-key, undecided keysystem but probably AES or Serpent, depending on whether I can find any proof of AES being broken) his copy of the group password G1. The group password is then hashed once to G2 and used for decrypting all the files within the group (same encryption method). Hence, it doesn't matter which of the users in the group decrypts the file, they all use the same password and can still use private files. IE, the group policy implemented 100% securely. Note, each user must have his own distinguished login account (obviously). This moves the security problem back into the world us computer nerds escape and can't prevent from malfunctioning. The real world, that is. If you are being threatened you will give your password. If you're corrupt, there's no stopping you. The only danger / flaw that I can think of right now is that for changing the group password you need everybody in the group to be present, or to encrypt it using the old group password
Details for slice redundancy and independency:
Each slice encompasses the entire section directory table. This way, if you have but one slice you can still mount it and use whatever's available. Using reed-solomon coding it can be made redundant with the minimum of space used (not in mind-design yet, being put in there) yet providing redundancy. This way, with any given N nodes you can mount the fs and expect to be able to open a file, not saying much about performance (however, nowadays, if you're not running a 3d game in the background too you're probably wasting your processor). Thereby, if the files were encoded to require the minimum the network could support in terms of smallest sublan and encode each file with that as segments, and the available number of slices as total number, any subset will do. So, any sublan of required size will also work, and contain all files marked as such (FS level setting even, so that works pretty nicely). All that's undecided atm is whether it's read-only if not all the other slices are present, or that a log is kept with changes for the others. This is complex, since you can also get collisions and stuff like that.
Re:Filesystem for Brendan's OS
Hi,
As for speed, the VFS cache will store unencrypted data. Worst case performance is going to be severely effected by networking overheads - basically performance will suck with or without file system encryption (unless the data is already in the local VFS cache).
The VFS cache runs in it's own address space and can't be accessed by anything else (except kernel code). This means I need to be concerned with the security of the native file system code, parts of the boot code, the user interface code (handles user logins and passwords), the VFS code and the kernel - any of these could be replaced with a corrupted (but compatible) binary to penetrate security in some way.
It does raise the possibility of resetting the computer and scanning through memory after reboot, even though the physical addresses of the data will be difficult to predict. It would be difficult (if not impossible) to prevent this in any case - for e.g. a simple text editor would also keep the data in unencrypted form. I haven't been able to find a way of preventing this either (at least not without secure hardware - a BIOS that clears memory on every boot and a memory controller that encrypts/decrypts when data goes to/from RAM chips).
One method I was thinking about is encrypting pages that haven't been used for N mS and using the page fault handler to decrypt them when accessed. This would at least minimize the amount of data that can be found after boot. It is possible to go too far (but it could be an optional feature), and I'm getting off topic.
BTW to get an idea of the level of security I want, take a look at these web sites:
http://www.windowsitpro.com/Articles/In ... cleID=3143
http://www.radium.ncsc.mil/tpep/library/rainbow/
Specifically "5200.28-STD - DoD Trusted Computer System Evaluation Criteria, 26 December 1985. (Orange Book)".
In summary, there's 4 ratings (A through D) where ratings C and D have sub-ratings. Windows NT scores a rating of C2 (unless you plug it into a network) and no OS has ever got a rating of A1. I'd like to reach a level of C2 (or higher) while networked.
I'm also thinking of asking the user what level of security is required when a new cluster is being created - Highest (kiss performance goodbye), High, Medium, Low and None. IMHO this would improve the number of uses the OS has - for designing the latest nuclear weapon use highest, for playing multi-user games use none, and for business use go for medium.
Cheers,
Brendan
It's an additional form of protection - if everything on disk is encrypted (and if free space is filled with random numbers) then looking for any data is going to be like finding a tiny needle in an extremely large haystack. It also means the file system driver won't know what's important and what isn't...Candy wrote:Why encrypt the OS files? They're pretty much free and open source, for all I care. You don't encrypt the obvious. That's just intentional slowing of your system.
As for speed, the VFS cache will store unencrypted data. Worst case performance is going to be severely effected by networking overheads - basically performance will suck with or without file system encryption (unless the data is already in the local VFS cache)
.The VFS cache runs in it's own address space and can't be accessed by anything else (except kernel code). This means I need to be concerned with the security of the native file system code, parts of the boot code, the user interface code (handles user logins and passwords), the VFS code and the kernel - any of these could be replaced with a corrupted (but compatible) binary to penetrate security in some way.
It does raise the possibility of resetting the computer and scanning through memory after reboot, even though the physical addresses of the data will be difficult to predict. It would be difficult (if not impossible) to prevent this in any case - for e.g. a simple text editor would also keep the data in unencrypted form. I haven't been able to find a way of preventing this either (at least not without secure hardware - a BIOS that clears memory on every boot and a memory controller that encrypts/decrypts when data goes to/from RAM chips).
One method I was thinking about is encrypting pages that haven't been used for N mS and using the page fault handler to decrypt them when accessed. This would at least minimize the amount of data that can be found after boot. It is possible to go too far (but it could be an optional feature), and I'm getting off topic.
Ok, add the device manager and any keyboard drivers to the list of vulnerable components (I should've thought of that before - intercepting keypresses is a well known technique for acquiring passwords).Candy wrote:Don't encrypt anything but user files. Ask the user for their password/code thingy/keycard upon login (at which time they pretty much need to use it anyway) and most of all, NEVER EVER EVER EVER EVER store the password in plain text or single-hash ANYWHERE. Only keep it in memory in single-hash.
BTW to get an idea of the level of security I want, take a look at these web sites:
http://www.windowsitpro.com/Articles/In ... cleID=3143
http://www.radium.ncsc.mil/tpep/library/rainbow/
Specifically "5200.28-STD - DoD Trusted Computer System Evaluation Criteria, 26 December 1985. (Orange Book)".
In summary, there's 4 ratings (A through D) where ratings C and D have sub-ratings. Windows NT scores a rating of C2 (unless you plug it into a network) and no OS has ever got a rating of A1. I'd like to reach a level of C2 (or higher) while networked.
I'm also thinking of asking the user what level of security is required when a new cluster is being created - Highest (kiss performance goodbye), High, Medium, Low and None. IMHO this would improve the number of uses the OS has - for designing the latest nuclear weapon use highest, for playing multi-user games use none, and for business use go for medium
.Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Filesystem for Brendan's OS
Hi again,
Some "thinking out loud follows..
The distributed file system and it's underlying mechanics are already mostly designed - the previous version of my OS implemented most of it (excluding sparse files, VMS style versioning and decent security, which are to be added in the new version). There's a file ("/etc/passwords") that contains an entry for each user and an entry for each executable file. There are a maximum of 127 normal groups, where any user can be given access to any groups. When a user logs in the user interface gets the user name and password and always allows them to log in. If the username/password match a user in the "/etc/passwords" file the user interface will remember which groups they have access to and the SystemID that is unique to that user. Every executable also has it's own unique SystemID.
Every file and directory has an access level which determines if it can be accessed by anyone, by anyone that has access to one or more groups or by a specific SystemID only. To open a file that is "specific systemID only" an executable can use it's own SystemID directly or use the user's SystemID indirectly (via. the user interface). If a file is marked as "anyone that has access to one or more groups" then the only way to open the file is indirectly via. the user interface (which uses the groups the user has access to). In general executables use their own System ID to access their own files only, and use the indirect/user interface method to access files that the user wants.
There's a special group which gives access to all files that belong to any executable's SystemID (but not user's SystemID's). The closest the OS comes to a root user is a user that has access to all groups (including the special group). This "super-user" still doesn't have access to any other user's files if they are marked as "specific user only" (they do have access to delete these files).
For filesystems, there's 3 different types. The first type is legacy file systems (FAT, ISO9660, etc). When any of these is mounted the legacy file system driver pretends that every file in the legacy file system has default permissions (where "default permissions" is specified by whoever mounted the file system). For example, if a normal user is allowed to access "/dev/fd0" they can insert a floppy and mount it such that no-one can access any of the files on that disk other than themselves.
The second file system type is native file systems. Every cluster has a "cluster key" and every node/computer in the cluster has this key. The cluster key is used when nodes join the cluster and when native file systems are mounted. The native file system driver looks at the partition and compares the partition's version of the cluster key to the OS's version before allowing the partition to be mounted.
The third file system type is boot images. There are 2 types of boot images - installation and normal. Installation boot images are used for installing the OS. During installation the OS asks the user for a cluster name and cluster password (the cluster name and password are combined somehow to create the cluster key). During installation the OS creates a "normal boot image" which is used to boot the installed OS and installed somewhere (e.g. in a special boot partition). The normal boot images contain a copy of the cluster key.
This is the mess I'm trying to make secure...
[More rambling to come]
Some "thinking out loud follows..
The distributed file system and it's underlying mechanics are already mostly designed - the previous version of my OS implemented most of it (excluding sparse files, VMS style versioning and decent security, which are to be added in the new version). There's a file ("/etc/passwords") that contains an entry for each user and an entry for each executable file. There are a maximum of 127 normal groups, where any user can be given access to any groups. When a user logs in the user interface gets the user name and password and always allows them to log in. If the username/password match a user in the "/etc/passwords" file the user interface will remember which groups they have access to and the SystemID that is unique to that user. Every executable also has it's own unique SystemID.
Every file and directory has an access level which determines if it can be accessed by anyone, by anyone that has access to one or more groups or by a specific SystemID only. To open a file that is "specific systemID only" an executable can use it's own SystemID directly or use the user's SystemID indirectly (via. the user interface). If a file is marked as "anyone that has access to one or more groups" then the only way to open the file is indirectly via. the user interface (which uses the groups the user has access to). In general executables use their own System ID to access their own files only, and use the indirect/user interface method to access files that the user wants.
There's a special group which gives access to all files that belong to any executable's SystemID (but not user's SystemID's). The closest the OS comes to a root user is a user that has access to all groups (including the special group). This "super-user" still doesn't have access to any other user's files if they are marked as "specific user only" (they do have access to delete these files).
For filesystems, there's 3 different types. The first type is legacy file systems (FAT, ISO9660, etc). When any of these is mounted the legacy file system driver pretends that every file in the legacy file system has default permissions (where "default permissions" is specified by whoever mounted the file system). For example, if a normal user is allowed to access "/dev/fd0" they can insert a floppy and mount it such that no-one can access any of the files on that disk other than themselves.
The second file system type is native file systems. Every cluster has a "cluster key" and every node/computer in the cluster has this key. The cluster key is used when nodes join the cluster and when native file systems are mounted. The native file system driver looks at the partition and compares the partition's version of the cluster key to the OS's version before allowing the partition to be mounted.
The third file system type is boot images. There are 2 types of boot images - installation and normal. Installation boot images are used for installing the OS. During installation the OS asks the user for a cluster name and cluster password (the cluster name and password are combined somehow to create the cluster key). During installation the OS creates a "normal boot image" which is used to boot the installed OS and installed somewhere (e.g. in a special boot partition). The normal boot images contain a copy of the cluster key.
This is the mess I'm trying to make secure...
[More rambling to come]
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Filesystem for Brendan's OS
Ok, from the last message this leaves me with 2 gaping security problems. The first problem is that the cluster key is stored within every partition used by the native file system, and could therefore be extracted and recycled (for e.g. taking it from a disk with data you should be able to use and inserting it into a stolen hard drive to give yourself access to data on the stolen drive). Encrypting all data in the partition using the cluster key would prevent any data from being accessed without the key, and wouldn't require that the cluster key itself be stored on the partition. This problem is a no-brainer (that's what you get for thinking out loud ).
The second problem is storing the cluster key (or the cluster name and password used to generate the cluster key) in the boot image. This is a 2 sided problem. The first part is that it's relatively easy to disassemble the boot code (or step through it with Bochs) to figure out any algorithm used to generate the cluster key (regardless of how complex this algorithm may be). The second part is that the data for the cluster key (or the cluster name and password) would be stored in the boot image in a not-too-hard to find location.
Now if a person knows the algorithm but can't find the raw data then they won't get anywhere. If they know the raw data but not the algorithm they'll also be stuck. Therefore I need a way to secure the algorithm or the raw data (but not necessarily both). However if the algorithm can be found by disassembling then the raw data can be found using the same method.
Therefore, my whole problem is reduced to securing the code in the boot image that encrypts the cluster key (or the cluster name and password used to generate the cluster key). Here I'm at a complete loss (any suggestions appreciated).
Cheers,
Brendan
).The second problem is storing the cluster key (or the cluster name and password used to generate the cluster key) in the boot image. This is a 2 sided problem. The first part is that it's relatively easy to disassemble the boot code (or step through it with Bochs) to figure out any algorithm used to generate the cluster key (regardless of how complex this algorithm may be). The second part is that the data for the cluster key (or the cluster name and password) would be stored in the boot image in a not-too-hard to find location.
Now if a person knows the algorithm but can't find the raw data then they won't get anywhere. If they know the raw data but not the algorithm they'll also be stuck. Therefore I need a way to secure the algorithm or the raw data (but not necessarily both). However if the algorithm can be found by disassembling then the raw data can be found using the same method.
Therefore, my whole problem is reduced to securing the code in the boot image that encrypts the cluster key (or the cluster name and password used to generate the cluster key). Here I'm at a complete loss (any suggestions appreciated).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Curufir
Re:Filesystem for Brendan's OS
Well I'd forget about obfuscating the algorithm. IMHO any cryptographic algorithm that relies on the algorithm remaining unknown shouldn't be used...ever.Brendan wrote: Therefore, my whole problem is reduced to securing the code in the boot image that encrypts the cluster key (or the cluster name and password used to generate the cluster key). Here I'm at a complete loss (any suggestions appreciated).
Which leaves the key.
As far as I can see the only real option here is to make sure it isn't on the same media. It could be on floppy, usb stick, mini-cd, swipe card, network server, whatever. Just so long as the key and the media can be physically separated. As you've pointed out anything else can be traced through from boot to determine the keys.
Re:Filesystem for Brendan's OS
Playing hide & seek with computer users is pretty pointless. You have to go to point X, and they'll just plain attach an alarm bell to point X to make it go *ding* when you hit it. You will not hold much security through that way.Brendan wrote: Now if a person knows the algorithm but can't find the raw data then they won't get anywhere. If they know the raw data but not the algorithm they'll also be stuck. Therefore I need a way to secure the algorithm or the raw data (but not necessarily both). However if the algorithm can be found by disassembling then the raw data can be found using the same method.
Therefore, my whole problem is reduced to securing the code in the boot image that encrypts the cluster key (or the cluster name and password used to generate the cluster key). Here I'm at a complete loss (any suggestions appreciated).
That left us with good algorithm design and common sense.
One: You cannot secure a computer owned by a dumbass.
Two: You cannot make more entropy out of what the user inputs other than what he inputs.
Three: Obscurity is NEVER a solution.
From these three points,
1. Never try to secure a computer against the will of the user.
2. Allow the user to input all the entropy s/he wants.
3. Don't hide your algorithm or data.
Concluding: Create a quite big hash (256 bits or more) to check the pass, use a non-related type of hash (say, encryption) for encryption, encrypt the cluster key just like the group password above and don't even bother to hide the mechanism.
Aside from the software part, there are just things you can't prevent. You cannot, by definition, indoctrination or proof (depending on how angry you get you will get any one of the three) make a system secure by just software. Any bits you create can be uncreated and recreated by somebody else to do the exact same as what you do, even if it is through single-stepping. You can only assume that
1. The user has secured the access to the boot section to just your OS
2. The user will not himself willingly leave the computer active & wide open while not present
3. The system box is physically impenetrable.
Assuming these three, you don't have to secure the boot section or loader or any bit of it, since it can't be modified. Not assuming any of the three breaks point one higher up, and hence you shouldn't bother protecting the user.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Filesystem for Brendan's OS
i guess you may like reading about OceanStore or Archival Intermemory ... those use a generic distributed hash table to store and manipulate files efficiently in a way that machines that possess a portion of a file may not be able to use that portion (only the owner that knows the 'keys' for all the portions can use it)
Re:Filesystem for Brendan's OS
Hi,
.
I guess my goal now should be making it as secure as possible (given hardware limitations), rather than making it secure.
For the highest security setting I'll make the user type in the cluster password every time a node is booted so that the cluster key (or data used to generate the cluster key) isn't stored anywhere.
For low, medium and high security settings I'll store the data needed for the cluster key in the OS's boot sector and clearly specify that this sector must be protected by hardware or other means. Removable/bootable media (floppy, usb stick, mini-cd, etc) can also be an option for increasing security (thanks Curufir).
For the medium and high settings I'll go the additional step of gathering/combining a collection of values from the hardware and using that as part of encrypting the key - I know it won't prevent anyone determined, but it can't hurt (it doesn't matter if the cluster's password needs to be re-entered if the hardware changes).
Obviously for the no security setting I won't bother with any of it.
@Pype: I'm currently looking into both OceanStore and Archival Intermemory - might take a while to digest.
@Candy: Also looking into SHA-1 and hashing algorithms in general - I currently know less than I need to.
Thanks,
Brendan
You're right - without secure hardware I'm chasing my shadowCandy wrote: Aside from the software part, there are just things you can't prevent. You cannot, by definition, indoctrination or proof (depending on how angry you get you will get any one of the three) make a system secure by just software. Any bits you create can be uncreated and recreated by somebody else to do the exact same as what you do, even if it is through single-stepping. You can only assume that
1. The user has secured the access to the boot section to just your OS
2. The user will not himself willingly leave the computer active & wide open while not present
3. The system box is physically impenetrable.
.I guess my goal now should be making it as secure as possible (given hardware limitations), rather than making it secure.
For the highest security setting I'll make the user type in the cluster password every time a node is booted so that the cluster key (or data used to generate the cluster key) isn't stored anywhere.
For low, medium and high security settings I'll store the data needed for the cluster key in the OS's boot sector and clearly specify that this sector must be protected by hardware or other means. Removable/bootable media (floppy, usb stick, mini-cd, etc) can also be an option for increasing security (thanks Curufir).
For the medium and high settings I'll go the additional step of gathering/combining a collection of values from the hardware and using that as part of encrypting the key - I know it won't prevent anyone determined, but it can't hurt (it doesn't matter if the cluster's password needs to be re-entered if the hardware changes).
Obviously for the no security setting I won't bother with any of it
.@Pype: I'm currently looking into both OceanStore and Archival Intermemory - might take a while to digest.
@Candy: Also looking into SHA-1 and hashing algorithms in general - I currently know less than I need to
.Thanks,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Filesystem for Brendan's OS
You might use the simple&awkward method of shrinking the actual filesystem on the USB stick by X kbytes and stealing that part for your random bits. Then, abuse those bits for checking it's the same stickBrendan wrote: For low, medium and high security settings I'll store the data needed for the cluster key in the OS's boot sector and clearly specify that this sector must be protected by hardware or other means. Removable/bootable media (floppy, usb stick, mini-cd, etc) can also be an option for increasing security (thanks Curufir).
.Alternatively, you can store the bootup code on it, effectively making the computer unusable.... or for fun, store the password hash stuff on it. Does make the user vulnerable for losing the key though...
Can you explain to me how this gives an advantage to security? It effectively locks the user to this one computer. You just said something about being able to move the computer elsewhere in the cluster without problem, what if the computer itself dies, in a small part (say, the NIC) which is then replaced? Will the OS no longer boot?For the medium and high settings I'll go the additional step of gathering/combining a collection of values from the hardware and using that as part of encrypting the key - I know it won't prevent anyone determined, but it can't hurt (it doesn't matter if the cluster's password needs to be re-entered if the hardware changes).
I recall some popular OS doing that after which they were nearly shot.
Just a short overview:@Candy: Also looking into SHA-1 and hashing algorithms in general - I currently know less than I need to
A hash function transforms a legible common text into gobbledygook (the word means the same if you do know what it means) of a specified bit size (and if done right, each bit has a 50% chance of being either 1 or 0). Ergo, you get an N-bit entropy value that is identical for this file, cannot be guided back to the original file and can be used for encrypting.
Hash functions are:
SHA (0, 1, 160, 256, 384, 512)
MD[4, 5]
RSA
Any common encryption function
Encryption functions work by combining your "key" into 128 bits and then encrypting a block of 0's with it. This constitutes a known-plaintext attack, against which most encryptions are good.
Schematic (as good as ASCII graphics go):
P -> C -> C2
Forward is very fast. Backward is VERY slow. You can hash it twice, getting to C2, check that with the on-disk one in plain text (which cannot be directed back to C) and use C as key to encrypt your stuff (say, the key).
I'm starting to repeat myself again, right? Anyway, consider trying *FS