Setup
I have a SQLite database which has confidential user information.
This database may be replicated on other machines
I trust the user, but not other applications
The user has occasional access to a global server
Security Goals
Any program other than the authorized one (mine) cannot access the SQLite database.
Breaking the security on one machine will NOT break the security on other machines
The system must be updatable (meaning that if some algorithm such as a specific key generation algorithm is shown to be flawed, it can be changed)
Proposed Design
Use an encrypted SQLite database storing the key within OS secure storage.
Problems
Any windows hack will allow the person to access the key for all machines which violates goal #2
Notes
Similar to this method, if I store the key in the executable, breaking the security will comprimise all systems.
Also, I have referenced windows secure storage. While, I will go to an os specific solution if I have to, I would prefer a non-os specific solution
Any idea on how to meet the design goals?
I think you will need to use TPM hardware e.g. via TBS or something similar, to actually make a secure version of this. My understanding is, TPM lets the application check that it is not being debugged or traced at a software level, and the operating system should prevent any other application pretending to the TPM module that it is your application. I may be wrong though.
You can use some kind of security-through-obscurity kludge, but it will be crackable with a debugger unless you use TPM.
Related
I'm just starting to learn about TPMs and was wondering if it's possible to restrict a signing key to a particular application? The idea being that only the application that created the key may use it to encrypt/decrypt data.
I believe there is analogous feature on MacOS that relies on having the application binary signed, and access is enforced by the keychain. Something like this is what I'm trying to mimic
TPM is an input-output device and it does not have a way to somehow reach back to the operating system and verify the application sending the command.
You have a couple of options, neither of which is exactly what you're looking for:
If you can have your application start as a system service on boot, then you could have the bootloader, or the kernel, measure your application into a PCR and then bind access to the key you want to restrict to that PCR configuration; then once the application has access to the key, it extends the PCR again. This approach guarantees that only your application can access the key, but it requires cooperation from the system firmware, the bootloader and the kernel and is quite complicated, as you will have to deal with PCR fragility going forward -- you will need to rebind access to the key every time any of the components in the system chain of trust change.
You could protect access to the key with a password, which only your application can provide. Now you have to figure out how to implement access to the password -- whether it's making the user type it in, or communicate with an authenticated service or something else. This approach is much easier to implement, but seems further removed from what you're looking for.
In Linux, there's a KDE Wallet (and GNOME Wallet) application, that stores passwords and other sensitive data. These wallets by default prevent accidental data access of application other than the one that stored the data.
E.g. if the piece of data was stored by the /bin/app1, then /bin/app2 won't have full access to that data, and the wallet will first ask the user if they really want to allow /bin/app2 to access the data stored by /bin/app1.
I find this feature important for some aspects of local data security for an application I participate in.
On Windows, a somewhat analogous UX is provided by wincred.h, but, as I currently understand, there's no any kind of per-application restrictions in it. It will provide the data access to any application started by the current user, and thus provide less security that the application-scoped defaults of Linux wallets.
Is there any way to achieve a similar application- (or vendor-) scoped security in Windows using only standard APIs?
I am considering encryption options for a new Sybase project. I am thinking that Sybase encryption is the wrong strategy because a) dba's can get in, and b) if and when we migrate to SQL Server or Oracle I don't want to deal with different encryption strategies.
Therefore I'm thinking to encrypt the sensitive data (symmetric encryption) in my Java code before storing it in the DB.
Now, the encrypted fields better not have their encryption key changed, ever, except in a very controlled environment, which for me effectively means never. So it's going to be a permanent password.
The question is, where should I keep this password in a way that it is accessible from the program but not accessible to anyone else. If it's in a properties file, any developer with access to our Git repo could see it.
We could hard code it in the source code, but good lawd, that's a bad practice.
We could generate it in source, like the 10th Fibonacci or 3!+8! that would be hard to locate, but it's still rather exposed.
We could have the sa's maintain it in the environment, but then where do they file it for future reference?
So many poor choices. Are there any good ones?
Simply using some secret code to create the key on the fly is both an insecure method and produces a poor key. The DB keep needs to be a random byte array. Keep in mind that the key needs to be in memory when used which will be most of the time for the DB.
WRT using the DB encryption, examine closely if the algorithm is fully specified and compatibility to another DB. There is also the possibility that the entire DB will need to be run-off and then added to a new DB, in that case using the internal DB encryption will be transparent.
You really need to consider needing to be able to change the encryption key in the future, what will you do if it is ever compromised? There are solutions to this dilemma. There may be a substantial performance penalty performing the encryption outside the DB, there is a substantial setup time for each new encryption operation. Also since not all columns will be encrypted (a good guess) that information is not shared by the DB and the outside encryption code, that coupling is not good for design nor maintenance.
Do not connect the DB server to the Internet, make it separate and connected with a non-networked connection such as direct Ethernet. This also limited the number of admin users of the only system that contains the encryption key.
Another important part of the solution is to restrict admin access to the server. This includes requiring two-factor authentication as well as severely limiting the number of administrators. You need to control the second-factor to physical serial-numbered devices owned by the organization so that they can be positively retrieved on personnel changes and not copied. Personally I favor RSA SecureID (or similar) hardware devices, there is positive control.
Finally in answer to the question, keep the key in a file on the DB server secured as above, that is with no Internet access and restricted admin access.
I have programmed a system for internal behavior reporting for my company's intranet. I should not have access to its data (not being part of the controlling committee, but I have.
I've locked my account away from the data, but I could unlock it. I could store the data in an encrypted format, but, even if chosen by someone else, I should store the salt somewhere and hence read it -> decrypt the data.
From a theoretical point of view (I'm not talking about a particular system or framework or utility), how can I not have access to the data stored in a system I have complete control of?
Seems to me that you could just set passwords such that only one user has access to the database, then allow someone else to set that password. It would make maintenance a bit more tricky, but then again a database shouldn't need a ton of maintenance on a tool like this once all is said, done, and thoroughly tested.
If this is internal, it would be nothing to setup a dedicated, physically secure WAMP or similar machine that's solely dedicated to this purpose. Have someone else tweak root passwords and store them with the "committee" and you're off the hook, in theory.
I suppose if one was to be completely paranoid, one could build a web service to isolate the database completely on a separate network from the reporting functionality. In theory, you could setup the web service on a remote machine that your access is removed from, then use the front-end to collect data and pass it to the webservice. From there, it's completely out of your hands, with no "data out" webservice to retrieve data.
Security is always a messy subject. I've worked in banking, ecommerce, and sports (drug testing) environments where I'm knee-deep in confidential data and it is more than just a bit scary. At some point, you just have to do the best you can do, document your safeguards, be "read in" on proper protocol and required background checks, do thorough testing with independent testers, and then just maintain complete transparency. In the IT world we have access to a ridiculous amount of information, and that's never going to go away.
The basic answer is Mandatory Access Control. The kind of access control most computer user are familir with is Discressionary Access Control. In DAC (Discressionary Access Control) everything on the computer is owned by a user. Users can grant access of an object (file, service, peripheral, memory, etc) to another user. Users can even transfer ownership of an object to another user. In MAC (Manditory Access Control) at least some objects are not owned by any user. The rules governing how users can access or interact with these objects are fixed and unchangable by any user.
In your example the data generated by the reporting system should be protected by Manditory Access Control, but the reporting system configuration may be owned by you. So you can control how the system behaves but not have access to the data it generates.
Microsoft began implementing MAC with Windows Vista. In Vista it was called Mandatory Integrity Control (MIC).
Linux can implement MAC with SELinux or AppArmor.
Mac OS X uses an implementation of the TrustedBSD MAC.
So, why isn't MAC used more often?
I takes effort. It is not easy to set up MAC, and it is hard to change once it is set up. It can be complicated. Most systems and services are built on the DAC model. Turning on MAC often makes services stop working.
What are some effective and secure methods of securing SQL queries?
In short I would like to insure that programmers do not see the passwords used by the application to perform queries. Something like RSA or PGP comes to mind, but don't know how one can implement a changing password without being encoded in the application somewhere.
Our environment is a typical Linux/MySQL.
This might be more of a process issue and less of a coding issue.
You need to strictly separate the implementation process and the roll-out process during software development. The configuration files containing the passwords must be filled with the real passwords during roll-out, not before. The programmers can work with the password for the developing environment and the roll-out team changes those passwords once the application is complete. That way the real passwords are never disclosed to the people coding the application.
If you cannot ensure that programmers do not get access to the live system, you need to encrypt the configuration files. The best way to do this depends on the programming language. I am currently working on a Java application that encrypts the .properties files with the appropriate functions from the ESAPI project and I can recommend that. If you are using other languages, you have to find equivalent mechanisms.
Any time you want to change passwords, an administrator generates a new file and encrypts it, before copying the file to the server.
In case you want maximum security and do not want to store the key to decrypt the configuration on your system, an administrator can supply it whenever the system reboots. But this might take things too far, depending on your needs.
If programmers don't have access to the configuration files that contain the login credentials and can't get to them through the debug or JMX interfaces then that should work. Of course that introduces other problems but that would potentially satisfy your requirement. (I am not a Qualified Security Assessor - so check with yours to be sure for PCI compliance.)