NOS File System Encryption Strategy
The Ultimate File Security System
This will use up quite a lot of disk space, and it may slow down file access, but it should make it virtually impossible for an unauthorized person to read the contents of a file. I’m thinking of something that would defeat NTFS DOS and the like from gaining access to NTFS files
Use 3 keys and an algorithm and several different file location keys.
First, when the OS is installed on a machine, during the install process it creates a key in the registry using a random number generator. Now – there is no pointer or variable or other easy name for this key. It is randomly generated and hard coded into all aspects of the OS that needs to use it. So that even if someone wrote a hack that could access the file system without the OS loading, they would not be able to search and find this key, b/c there’d be no references to it. Every reference would be on install hard coded with this unknown random value. In this key a sub key is created for EVERY single file on this machine’s file system. That sub key is the file name, and the value of that key is a 64, 128 or 256 bit key (depending on security level). That’s key one. Embedded in the file itself is another 64, 128 or 256 bit key – for the user ID (or group) that has access to it. And finally there is a 3rd key (again 64, 128 or 256 bit) stored in the User ID (or group) that has access to that file. The User Key, and the O/S key would need to be combined in a cipher algorithm to generate the resultant value, which would need to be then combined with the key in the file header with a second algorithm to decrypt the file for access. Now for every user or group that has access to this file, there would be another 64, 128 or 256 bit key added to the header of the file. SO – the user or group ID who has rights to it would also have another value in it’s file access key, and that would be the sequence number. That sequence number would be assigned by the file based on the number of other accesses that were already assigned.
Example: File is created on computer 1. The O/S for computer one creates a key named after that file, and puts the 64bit value in it. The user who created the file gets a 64 bit key in their user registry profile, and a sequence number of 1. The file gets it’s own 64 bit key, in it’s first key position. Then the administrator gives user 2 access to the file. Well – computer 1 still has it’s key, which is always used by the O/S running on Computer 1 before it allows the file to be opened. And User 2 gets a registry entry with his own registry key for that file, and file gets a second key (in it’s key position 2 slot), so the user 2 person gets a sequence number of 2 after his key. The O/S and the user value are combined via the algorithm, and the file value is also combined for it’s own unique decryption process. As you can see, while the file is encrypted already, these 2 new random values will also have to be able to decrypt the file Basically, the file will be scrambled by one master encryption, but then the key to unlock that encryption will be encrypted by the other 2 keys, so that each user or group has it’s own unique decryption path. To say another way: When the file is created, an encryption key is generated and the file is encrypted with that key using an algorithm. Then, that Encryption key is itself encrypted by the O/S File Encryption Key and the User File Encryption Key. .When a second user is given rights to the file (they can only be given access to a file from someone who already has access to the file), then the File Encryption key (which is encrypted) is DECRYPTED by the ID assigning the rights to the new user. Then the O/S File Encryption Key and the other User’s new User/Group File Encryption Key is used to Encrypt the File Encryption Key. Again, and that’s put in file encryption key sequence slot 2. So now the file has 2 decryption keys. One decryption key that is encrypted by OS File Encryption Key and User 1’s File Encryption Key, taking up file encryption key slot 1 (the original one), and the second Decryption Key, which was encrypted by O/S File Encryption Key and User 2’s unique File Encryption Key, stored in the second sequential position of the file’s encryption key slot 2.
Now – for normal file access, no matter what computer your connecting to the computer the file resides on, the unique key for the o/s who’s storing the file is needed, and there’s no way to find it by just hunt and pecking b/c it’s statically stored in the O/S itself. Also – even if someone could find the key on the HD of the machine in question – say using a hack like NTFSDOS, and just manually searching until they found a file in the registry that had the file data and then they found the key, THEN they’d also have to find the registry that stored the user ID’s and then find a specific USER or GROUP ID with access to the particular file in question, and then they’d have to GUESS what sequence that particular user had access to the file, so they’d know which part of the file’s encryption key header was the correct encryption key. This person would also have to get hold of BOTH Algorithms that were used to encode the file (or more specifically algorithm 1 which encrypted the file by combining the first 2 keys and then algorithm 2 which encrypted the key encryption for said specified User ID or Group).
Now – that alone would make it hard enough, but if one then setup the environment like a standard NT domain – with the user ID’s on a PDC but the files stored on a file server, then the USER profile registry keys for file access would be on a completely different system. That would make them inaccessible to someone who’d presumably booted the machine to an NTFS dos type disk. So even if they were clairvoyant enough to find the randomly coded registry entry that stored the O/S keys, and even if they knew exactly which specific encryption key sequenced in the file header to pick, and if they had both algorithms, they still would have to randomly generate a 64, 128 or 256 bit 3rd encryption key (from the User profile access list) which would be on a separate, and inaccessible machine, and then run that thru 2 sets of algorithms, to test to see if that’s the one that would fulfill the sequential decryption, and therefore open up the file for reading – these algorithms could be designed to take extremely long times to solve when the wrong keys are supplied (make them resolve to infinite iterations except for specific correct values of keys. And of course, only 32 bits offers about 65million possible combinations, so 64 bits is 65 million squared, each one having to be tested across 2 sets of really tough algorithms – the goal being that it would take a computer an eternity to process them all.