Given a requirement from a customer, they want to anonymize their DB for their development team, but they are asking if primary keys can be encrypted. By looking a bit into the oracle TDE documentation seems this is not possible...
Is there an approach to this?
Related
I'm writing smart contracts on Algorand, and want to know how to make them production-ready. How can I securely pass private key, for example when creating smart a contract and sending it to chain? It feels insecure to store the passphrase or private key to the dev computer.
Key management is an extremely complex topic and if you are writing an application that is expecting to move millions of Algos, I would strongly recommend consulting a security expert and do a full audit.
There are many questions to ask and I'm just highlighting a few there:
Do you want a custodial solution (i.e. the service has the key) or a non-custodial one (i.e. the user has the key - drawback: if the user is less technical, they may lose their keys with no recovery solution) or a hybrid one?
What does the key allow to do?
Q1: Custodial / non-custodial solution?
a. If you want a non-custodial solution, use MyAlgo Connect, AlgoSigner, and/or Wallet Connect. This is easy and really limit risks on your side, but non-technical users may lose keys.
b. A custodial solution is much more complex as you hold funds. Beyond technical issues, there are also legal issues.
c. Hybrid solutions may use multisig or smart contract to allow the user to use their non-custodial keys most of the time, but have a complete cold storage key that is used to manually recover accounts in case things go wrong. Complete cold storage means slow to access but also more secure.
Note that you can also have custodial key management by default and allow for non-custodial key management for advanced users.
Q2: What does the key allow?
There are many times where you actually don't need the stored key to do everything possible.
For example, if you are just transferring ASA, you may use delegated logicsigs. See the forum.
However, if you really need a custodial solution done with storing your key, you most likely want to have a separate server to handle the private key. This server would run a very simple easy-to-audit code. Ideally, it would use an HSM, but unfortunately last time I checked, there is no easy-to-used HSM for ed25519 used on Algorand. Shielded/Hardened VMs may be a good idea too. If you have your own server, YubiHSM may be an option to securely store your keys (it supports Algorand).
If HSM are not available, you should at least store the keys encrypted under a KSM key or in a "Secret Manager".
This server would require strong authentication from the other services and log everything. You can then have other services checking logs. There can also be additional safeguards in case of too many transactions.
I would also actually recommend using multiple servers over multiple clouds, if possible managed by different people in the organization. You can then use multisig. For availability and recovery in cash of crashes, you most likely also want to have some of the multisig keys available in complete cold storage.
Hope this helps.
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'm working on a small project that stores an encrypted password, using code from Simple insecure two-way "obfuscation" for C#. The password will be stored locally on the user's PC, and there is no database involved to store a second key.
I will need to share this code up to my team and, eventually, possibly to other teams. Since it's 2-way encryption, I don't want the key/vector information to be shared, and anyone be able to access the passwords generated with that key/vector.
I thought about using some mishmash of machine name/user SID to generate the key/vector on a per machine/user basis, but it would be easy enough to get that information if you wanted it.
I thought about having the user generate a random key to start with, but hey, you have to store that somewhere, too.
Am I thinking too complicated about this?
What are your suggestions to do this the most securely?
I am using Bouncy Castle to generate a public/private keypair and using it for encryption tasks.
What would be the best way to store the keypair securely?
I have been unable to find a way to store on the devices keystore. Storing on a txt file wont work because it is as insecure as it gets. I could store it in RMS but then how does one secure this from a person with enough motivation to snoop?
Data store Update:
Problem with RMS is that if the application is saved in the mem card then the datastore is easily accessible to anyone.
As you're already using Bouncy Castle, then just implement a simple PBE (password based encryption) scheme to allow the records stored to be encrypted. For an example on how to do this have a look at the simple application I wrote many years ago.
http://www.eaves.org/jon/j2me/pocket.shtml
If you look at the .record package, you can see what I've done to encrypt and store individual records.
The "downside" to this approach is that you need to get the user to choose a "passphrase" and use that as part of the PBE. I'm not aware of any other approach to do what you want to do, and maintain security over the information stored. Any attempt to "hide" the key is futile, and insecure.
see my answer here, its secure to save in record store
How to sort recordstore records based on a certain field in it?
every application have its own record store and removed on application uninstall
Has anyone got practical experience or a reference for a scheme that implements a key management scheme that would comply with the PCI DSS security standard?
There are obviously quite a few implementations around given the number of companies compliant with PCI DSS but trying to find details of them is tough. When it gets down to storing private data the discussion normally stops at which encryption algorithm to use. After that there's normally a statement about appropriately storing the private key but no discussion about practical ways to do it or things like periodically changing the key or providing the key to applications etc.
Specificlly I'm interested in thee requirements from sections 3.5 and 3.6 of the PCI DSS standard.
3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.
3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.
3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.
I've had a look at the NIST Cryptographic publications as the PCI DSS requirements document suggests but apart from recent notes of a Cryptographic Key Management Workshop there doesn't appear to be much there in the way of real implementable schemes or standards.
As to what I'm trying to do it's not:
Store passwords + salts as one way hashes for authentication,
Choose a strong symmteric algorithm for data encryption,
Avoid needing to store private data in the first place.
Avoid the need for key management with other mechanisms: physical security, database security, dragons and wizards etc.
All of which are valid concerns but in this case are not the answer. The nuts and bolts of my requirements are in a different SO question .Net Design pattern for storing and retrieving sensitive per user data but it all boils down to key management hence this more refined question.
I'm familiar with the pain you're going through. We struggled to update an old EFT system towards PCI compliance. Key management was certainly (from my software point of view) the most challenging part.
I think I also stumbled into the NIST Recommendations for Key Management that Martin posted, and got incredibly frustrated with the lack of concrete examples.
ANSI X9.17 - Financial Institution Key Management is probably the most relevant to your needs, with PCI-DSS. Good luck reading it though, the document is a massive collection of TLA's which I know I certainly struggled to read. (X9.17 is updated yearly, and latest version is now: NIST SP 800-57 Pt. 1 Rev. 4 )
When frustration turned to desperation I stumbled into The Electronic Money Mill which is a fictional tale, with a good number of relevant technical references. Chapter 17 discusses X9.17 and may help with the understanding.
From all this reference material I designed a key management system that our auditor was pleased with. The design documents are fairly lengthy, but in summary the idea is that you have your Data Encrypying Key protected by a Key Encrypting Key, and the Key Encrypting Key is stored on a physically separate box, itself protected by a Master Key.
My implementation was to have a Key Server application running on a windows box. This application required entry of two separate 'key server master keys' before it could be used. These keys would be known only to the key server administrators. These keys are xor'd together to generate the Master Key, which is stored only in protected memory whilst the application is running. Application can then automatically generate cryptographically strong Key Encrypting Keys, which are stored in encrypted form using the Master Key.
Applications that have a need for encryption will request a Key Encrypting Key from the Key Server. The KEK is used by the application to encrypt/decrypt the Data Encrypting Key, which can be stored securely with the application data.
Good luck. I hope you also find it an interesting challenge!
Have you seen NIST SP 800-57, Recommendation for Key Management?