Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Let's have N devices each has a unique name DEVICE_1, DEVICE_2, .. , DEVICE_N
Devices broadcast their names so that other devices can start communication with another device from the same group (according to the format of the name).
The device name is encrypted so that nobody else who is not in the group can see the name and thus can't fake the name.
There's one key for symmetric encryption used by all devices to encrypt their names and decrypt names of other devices.
The problem is that the key for symmetric enctyption is stored in the device. So if somebody hack into the device, reads the key, decrypt the name, change its name to existing name
of other device and ecrypt it, everybody else think that it's somebody else.
EDIT the idea below is wrong since the device must be able to decrypt the name offline
I came with a solution of storing the key in database on server so the name is encrypted on server once the device has registered to the service. This will work even when the name of the device has
changed since the change of name is always uploaded to server so we can do the encryption on the server again.
The only vulnerability left is if somebody breaks into the database and reads the key...
EDIT END
Any idea how to solve this?
Oh, I forgot, the devices can't communicate before they know each other's name so assymetric cryptography wouldn't help because I even don't know there's some device from my group out there.
First of all, it seems that you try to achieve authentication and integrity by encryption - it is a mistake. Even if you use more relevant cryptographic primitives like signature or MAC (Message Authenticated Code), while you use the same key for all the devices, you are exposed to problems when you use them if one of the devices is being hacked.
I think each device should have a public key, and the database should distribute them (with the corresponding identities) to the other devices.
The public keys might be signed by a trusted party (for example CA), such that given a public key and a signature, it is possible to detect corruptions.
Then, using the public keys and the identities, you can create pairwise symmetric keys (notice that every device should store N symmetric keys - exactly as the number of public keys it stored in this solution), and use them to communicate efficiently.
You can use only one key, but again - this is very problematic.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are using Firebase Database Rules to secure our database. We also would like to add additional security by encrypting sensitive user information. Right now our encryption approach is:
Encrypting user data client side with a public key before the user writes it to the database
Decrypting with the private key on the server before delivering the data to the user through a GET request
Our private key is a string hardcoded in the server code. We want to secure the private key using KMS’s encrypt/decrypt methods, and store only the encrypted private key in the code.
An encrypted private key will be stored in the server code, and it will be decrypted using KMS on runtime, this way the developers won’t have access to the private key.
However, we wasn’t sure if there could be a better approach using Cloud KMS. Can KMS be used for client side encryption and server side decryption together? Or what is the best practice to use KMS to enhance database encryption?
Your question is a good example of why you should not implement encryption and data security unless you know what you are doing. Your implementation is severely flawed. Asking is a good first start, but there is a lot to cover.
Normally, you do not use Private/Public key pairs to encrypt data. Public-key cryptography is used to securely negotiate a symmetric encryption key. Public-key cryptography is also very expensive in CPU time compared to symmetric encryption.
Example. Why bother to encrypt the data at the user side, if you are going to decrypt it on the server before sending to the client?
Hardcoding the private key in the server code is a horrible practice. This almost guarantees that your key pair will be leaked.
Yes, using Cloud KMS will be a huge improvement for you. This will make security easier to implement and remove some of the management headaches for encryption. However, you will need to understand KMS and encryption best practices. Poorly designed security is very easy to break. Poorly designed security is very easy to lose track of rending data inaccessible.
In simple terms, you will want the following at a minimum:
Encryption Key Management
Key Rotation
Encryption at Rest
Encryption in Transit
Separation of responsibilities (admins cannot decrypt data)
Unless there is a good design reason or compliance requirement, you should not be encrypting data at the client - the client should not be managing keys. The data should be transferred securely using an encrypted transport protocol. Your server should be controlling and managing encryption for the database. The database should be encrypting data at rest also.
I could go on and on and this is why there are large books written on this topic.
I think your plan sounds like a decent one. Yes, you can improve security by wrapping your private key with Cloud KMS; then, you could put the wrapped key into your source code or your application's configuration files, then when it starts up, unwrap to get the private key. This would let you mitigate the risk of having the key which can decrypt the database handled by your developers.
Another approach would be to not use local crypto: instead, you could call KMS to encrypt and decrypt data every time a row is written or retrieved. This might give you some benefits (the key isn't even known by your binary; you get rotation, etc., as a part of the KMS solution; and you can get logs of every key use), but would have some costs (you now depend on the KMS service for every request; latency of KMS requests may decrease performance; the request-per-access costs more money than just unwrapping on startup; and you depend on channel encryption to protect the user data as its sent to your service, since you'd now be encrypting service-side).
KMS now also has asymmetric crypto support (docs here) so you could combine the two: do public key encryption client-side then use the asymmetric KMS key to do decryption for each request. Pros & cons are similar to above, except that you can keep the same data exposure and client-side encryption that you currently have.
I agree with another answer that the security benefit of doing client-side encryption here isn't entirely clear since the service has the authority to decrypt; it's not clear that having it do the encryption as well would result in increased risk. But using public key as you describe doesn't clearly lead to increased risk (presuming you do it well and correctly, not a trivial matter).
Thanks for your question and for using Cloud KMS; please let us know if you have any further questions we can help with!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am working on an application which has both web and mobile java interface. Web is only a "spectator", therefore can't alter database in any way. On the other hand, the java interface can (and it often does). I don't want to use self-signed certificate so I came up with this solution. What I want to ask is whether it could be considered secure or if there is any better, more efficient way to do this. I am a bit paranoid person so please take this in account.
When an android device registers itself, I save pasword as sha256(pass + pass). This is the only time the device has to send password as a plain text. This function produces what I'll call [hash] and it will be stored in my database.
When logging in, the device sends new hash created by sha256([hash] + unixTime) as well as the unixTime. I need to use the [hash], otherwise I would not be able to verify the password. The server will try to reproduce the product of the function and if it succeeds, user is verified. Sent unixTime will be inserted into database afterwards, so I can also check, whether this time hasn't been used yet (if unixTime is less OR equal than saved, therefore forged / from past, I can safely discard it as invalid)
Similarly, all other packets which need authentication will be validated this way (so every packet = new hash)
Note: all hashes are converted to hex, just to spare a few bits.
What I want to ask is whether it could be considered secure or if there is any better, more efficient way to do this.
"Could be considered secure" isn't asking much. I consider it secure against unauthorized login, as long as an attacker doesn't have access to the device, the network, or the database. A straightforward system that transmits and stores the password in cleartext would also be secure in that kind of situation. It would make more sense to ask with a specific security goal and threat model in mind.
Here are a few key problems that this design:
If an attacker can get the hashes from the database, they can log in by computing sha256([hash] + unixTime) without knowing the password.
An attacker that controls the network can intercept a sha256([hash] + unixTime), unixTime pair and use it verbatim. SSL would prevent such an attacker from obtaining those values.
If an attacker can get the hashes from the database, they can quickly try hashing passwords and see which users' hashes match. Salted hashes would prevent this.
It sounds like in addition to saying you don't want to use a self signed cert that you're also oppossed to using https even if it was a certificate issued from a trusted certificate authority; is that so and if so why? Having your password in plaintext even once is a significant vulnerability; that plaintext password is free game to anyone running packet capture software on machines that your network traffic traverses, not to mention that if you've chosen the wrong http method then those passwords will definitely end up sitting in the logs of any proxies along the way.
I'd also suggest that at the least you store your passwords properly salted. Not doing so results in a number of security weaknesses if your database is retrieved by a malicious party; for example pre generated rainbow table attacks would be feasible as well as an attacker being able to easily identify which users have identical passwords thanks to the hashes matching. There's a great Owasp writeup on the key things you should look out for here.
Is using a solution like oauth an option? I recently implemented Google OAuth in a mobile application and it was pretty straightforward in combination with ssl. No need to reinvent the wheel, especially when it comes to crypto and user auth ;)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Me and other developers in my office encountered in this scenario :
We are an Insurance company which needs to send files to our customers.
But we need 2 things :
From The customers Point of view :
How can I be sure that this file that was sent to me is from My insurance company ?
How can I be sure that this file is the original file that was sent to me ?
for 2) i thought that I should use md5 and send it to the users - but this also needs its genuine... so Im in a dead end.
What is the best approach for this ?
p.s.
We don't want to open a virtual drive on our site - and let each costumer a username and Password.
Looks like you need Pretty Good Privacy
http://en.wikipedia.org/wiki/Pretty_Good_Privacy
This is exactly what public key encryption (aka asymmetric encryption) was made for.
You have a public key and a private key. You give the public key out to anybody you need to send files to. There is no need to protect this, you could post it on your website. Anything encrypted using your private key (which is secret) can only be decrypted using the public key.
So if your customers can use your public key to decrypt the file it proves it originated from you since you're the only ones with the private key.
If you're talking about email, take a look at digitally signing the email with S/MIME. You use a certificate issued by a CA (much like SSL), which proves both that your organization sent the email and that its contents have not been altered.
S/MIME validation support is built in to many email clients, including Outlook.
You need to cryptographically sign the files somehow, and the customers need to have a way of verifying these signatures. There are plenty of ways:
PGP
S/MIME
Distribution via HTTPS.
Do get this right, you have to think about what you are trying to protect, and what it is worth to you and to the customer to protect it. Is it the authenticity of the file when it is stored at the users computer? Do you want to avoid customers tampering with the file? Do you want to avoid someone tampering with the file before it gets to the user?
If the data you want to share is text documents, Adobe has support for signed pdf files. That might be worth examining.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Friend of mine wanted introduce in his company emails PGP encryption for exchange mails with clients. He asked me to write easy app supporting that.
I found useful dll wrapper - so it seems to be not very big deal to write app.
What puzzles me is security aspect. (I dont want to push him on the mine)
I know PGP uses private/public keys combination. It uses also passphrase to encrypt private key.
This is clear
But what if one of co-workers change passphrase before leave company?
Does it mean that firm will be not able to open archive mails with communication to clients?
(Sounds like best way to blackmail, vengeance etc...)
Assumption: all users' keys (pub + prv) are stored on users (network) home drive and backuped.
1st generated key's password is stored in envelope in safe box.
So keys can be restored - but (I guess) keys can be useless when you dont know current password used for private key encryption?
(Correct me if I'm wrong!)
I wonder how you archive it! What's your experience?
The encrypted private key is a blob. PGP usually stores it in a "keyring", which is a data structure of its own, but nothing prevents you from having a copy of that blob somewhere else (e.g. on a CDROM stored in a safe). This is generically known as "key escrow": a backup copy of the key, to be used if the key holder becomes unavailable (this includes "he was fired" but also "he was hit by a bus").
A user changing his passphrase would reencrypt his private key (the same private key) with his new passphrase, but the escrowed copy would be unaffected, and since this is the same private key, the situation can be recovered from.
What you need, however, is a company policy which enforces key pair generation through the escrowing system. A basic escrowing system consists of a system administrator with a PC: the sysadmin creates the key pair, stores a copy in the company safe, and hands the key pair to the user (e.g. on a USB stick). The user then imports it in his own keyring, with whatever passphrase he sees fit. The important point is that no employee shall ever use a key which has not been generated in such a way.
For digital signatures, situation is different: no data is lost if the private key becomes unavailable, and previously issued signatures are still valid and can still be verified. Normally, digital signature keys are not escrowed.
In my project, there will be about 500 Bluetooth devices installed over the city and about 20 PDAs used to update these devices.
The devices should be not be visible to anything except the PDAs and I'd like to avoid the troubles or pairing each device to each PDA.
Is there any way to pregenerate 10,000 link keys (for each device-PDA pair), knowing their device addresses, so that link keys for each of the devices could be uploaded all at once during the firmware upload process?
define a shared secret and use the mac-addresses as salt.
with this, you are able to generate a key, which is known on both systems.
or something like that :)
pseudo:
key = int(private part (shared secret) + public part (mac-address))