If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
Advice on securing a sensitive Access database
In article
, The Frog Thu, 17 Apr 2008 01:59:10 writes [...] I hope this helps a bit. More than a bit - I think I now do understand the issues and techniques involved. I am very grateful for you long and comprehensive reply. I am now going off to have a quick read of Cryptography for Dummies. I'm sure I'll be back Many thanks again. -- Les Desser (The Reply-to address IS valid) |
#22
|
|||
|
|||
Advice on securing a sensitive Access database
Anytime. Come back with any questions you may have and I will do my
best to answer them. Another good read for a budding cryptologist is a book by Simon Singh called 'The Code Book'. It gives you an understanding of what the different types of cryptography are as well as how they have and are used. Looking back through history with this book shows quite clearly where systems have failed not because the cryptographic standard was insufficient, but rather that the implementation was insuffucient and made an otherwise strong cipher vulnerable. Its all in the way you do it :-) Cheers The Frog |
#23
|
|||
|
|||
Advice on securing a sensitive Access database
In article
, " Wed, 16 Apr 2008 01:24:04 writes The AES key for each table was stored as a table property with DAO code, encrypted Asymmetrically (public / private), for each user that had access to the table. I have been going carefully through your posts and am progressing well. Just one query at this point. Why cannot the AES key be encrypted with a second symmetric key rather than Asymmetric? In any event, you are not publishing the public key and the private key has to be kept secret so why not just use AES a second time? -- Les Desser (The Reply-to address IS valid) |
#24
|
|||
|
|||
Advice on securing a sensitive Access database
Hi Les,
The use of the Public / Private key pairs is simply for the separation of users from one another. By using the key pairs for each user you have the ability to grant / revoke permissions on a table by table basis, or alternatively remove a user from access completely without interrupting any other users of the system. In essence, if you were to use a single AES key as the access code for all users, say for example they type in a username / password and get the AES key back in return, you have the problem of how to secure that AES key. Where would you store it? By using the public / private key pairs you dont have to worry about that problem because the only exposed information is able to be publicly exposed. In this way you can store any AES key or keys or data with a public / private key pair. The question then becomes why not use the public / private key pairs as the primary means of encrypting all the data. There are two reasons for this, the first being speed. Public / Private key encryption is much slower to operate than symmetric encryption such as AES or DES etc... It is theoretically possible to operate this way, but the 'horsepower' needed to do it in a timely manner for any significant amount of data becomes a serious problem, even with current hardware. The second reason is that you need to keep a 'central' copy of the data available to be worked with for each user. If you use Public / Private to encrypt this data you would require that each user has a unique copy of the data as only their key pair could properly would with that encrypted copy. In short then, the basis for using the two schemes together is simply one of practicality. We use the public / private key pairs to secure a unique (user specific) copy of the 'central' AES key(s) that are needed to get at the data. Each user logs in, their private key generated from their password and username, decrypts the AES keys as needed to access the data they are allowed to access. When you need to remove a user from the system you can remain confident that that the data will remain secure and simply remove the users username / password from the system and not disrupt any other user in the system. In theory you could also use AES or another symmetric cipher as the means of securing the other AES keys. The condition being that you still maintain the separation between the users username / password key, and the key(s) needed to get at the data. If you do this it can work fine, but you will lose the ability to operate with things like secure tokens and such which typically work with certificates and asymmetric encryption schemes. If you dont need / want the option to employ tri-factor security then you can go with the more simple username and password only. You would need to make some sort of check in the authentication system / login so that the app knows if the user has entered the correct data of course, same as before, then just make sure that a copy of the tables AES key is encrypted for each user with the users AES key. I think this should pretty much work the same for you if you dont need the extra authentication of a smart card / token. Is this what you were asking? I hope I understood you correctly. If you need more info just let me know :-) Cheers The Frog |
#25
|
|||
|
|||
Advice on securing a sensitive Access database
In article
, The Frog Thu, 8 May 2008 02:15:05 writes [...] Is this what you were asking? I hope I understood you correctly. Yes - just perfect. If you need more info just let me know :-) I'm sure I will be back Thanks again. -- Les Desser (The Reply-to address IS valid) |
#26
|
|||
|
|||
Advice on securing a sensitive Access database
We have progressed a long way and we are testing the encryption
functions and have seen some odd behaviour and wonder if there is a problem. We have a query that shows the original text, the encrypted string and then the decrypted string - it is working fine. However, there is a certain pattern of results that we do not understand where we have identical string values in different records (user name and event log text). In the case of user name (8 chars), we have records with identical strings and the encrypted values (32 chars) are totally different each time. So question one is if the initial values are the same why are the encrypted values not the same (we are not using an initialization vector) In the case of the log text (20 chars) the first 32 characters of the encrypted string is always the same while the remaining 32 are always different. So question two is why are we seeing this odd behaviour. We intend using an initialisation vector to stop this happening but would still like to understand what is going on. -- Les Desser (The Reply-to address IS valid) |
#27
|
|||
|
|||
Advice on securing a sensitive Access database
Hi Les,
I just want to make sure I understand this correctly so that I can answer properly. What I think you are saying is that when using the same (I am assuming AES) key to encrypt some text / data, that you are seeing different outputs in different parts of the program. If this is the case I suspect that the source of this lies in the string / plaintext to byte conversion (and possibly the reverse also). Theoretically the operation to encrypt (without padding) should produce the same result for the same text / data each time it is done if using the same key. Things to check for are these: 1/ Are the keys being used actually the same 2/ Is the data decrypting properly 3/ If you are operating the code "By Hand" in the editor and encrypt something does the result match the same when using the application 4/ Are the sections of code that are used to encrypt and decrypt the same? (ie/ is the process and encryption / decryption methods being used the same) 5/ Does the data decrypt properly? 6/ Is the source (plaintext) exactly the same when doing the testing. The most common issue I have come across was the conversion of the plaintext to a bytearray was producing different bytearrays. As it turnded out the code that was feeding the plaintext to the encryption algorithm was actually producing different plaintexts that looked the same on screen (so to speak) but were in fact different. This came in my case from some simple data type conversions that I wasnt handling properly. The root cause was the variant data type being used to house the plaintext instead of a string. When dealing with numbers in particular it caused issues. Using strict data types eliminated the problem. Aside from that, the only other thing that I could think of is that there may be an issue with the algorithm implementation itself. If you like we can try and beat the source code to death to see if there are any uncooperative lines of code :-) Please understand I am not asking to post your proprietary code here or data, just the algorithm implementation code so that if you think we need to dissect it we can. Please keep me posted, and try the "By Hand" testing with the same data multiple times to see if you get the same strange behaviour. Cheers The Frog |
#28
|
|||
|
|||
Advice on securing a sensitive Access database
In article
, The Frog Mon, 19 May 2008 01:37:51 writes [...] Please keep me posted, Thank you for your previous post. We have introduced an IV so the problem has gone away. I still want to understand what was going on so will do some more test when I can. One side affect of the encryption has surfaced. Obvious really, but did not think of it. If fields are encrypted then basically all indexes go out of the window. So to fill a pull-down list from a table, the whole table needs to be decrypted (we are using a query calling the decrypt function) and then Access has to build a temporary index to sort. For 26K records the decrypt is instant (query without sort) but with the sort it is about 16 seconds. Two solutions we can think of. Have a separate field containing the first character in clear text or equivalent ASCI code. Or introduce our own sequence field. Both solutions require these fields to be maintained every time the text is changed or a record created. -- Les Desser (The Reply-to address IS valid) |
#29
|
|||
|
|||
Advice on securing a sensitive Access database
Hi Les,
Yes, indexing can be slightly problematic. One thing I did to help was to populate a recordset with the results of the 'decryption query', and then did my sorting / filtering from there. It is much faster to operate in memory than off the HD. I dont know if this will suit your situation though. I found working with ADO disconnected recordsets quite efficient for this purpose, and you can keep the data secure even across the 'wire' this way by having a two stage process: 1/ first query simply gets the data 'raw' from the encrypted recordset still in encrypted form 2/ Make a function that takes the 'raw' recordset and returns a decrypted one. Let me know if you want to bounce this around some more. Cheers The Frog |
#30
|
|||
|
|||
Advice on securing a sensitive Access database
In article
, The Frog Fri, 23 May 2008 02:05:50 writes Let me know if you want to bounce this around some more. I would just like to tender my sincere thanks for all your help. The project is coming to an end - based primarily on your advice and help. Many thanks once again. -- Les Desser (The Reply-to address IS valid) |
Thread Tools | |
Display Modes | |
|
|