I've developed an app who run on 100 devices. Want to update it but if I install the new APK give me error. "Android App Not Install. An existing package by the same name with a conflicting signature is already installed".
I researched and found the problem.
I changed my SSD and that's why my debug.keystore file is gone at formatting.
I have found the RSA file in APK. Can I change my new debug.keystore with the value in the old APK?
I researched keytool. Can i use importcert and give two certificate in one debug.keystore?
It that will be possible, everyone can unpack APK and get your private key. Next time do backups before formatting!
I think Google explain it in documentation pretty well
https://developer.android.com/studio/publish/app-signing.html#secure-key
Maintaining the security of your private key is of critical
importance, both to you and to the user. If you allow someone to use
your key, or if you leave your keystore and passwords in an unsecured
location such that a third-party could find and use them, your
authoring identity and the trust of the user are compromised.
If a third party should manage to take your key without your knowledge
or permission, that person could sign and distribute apps that
maliciously replace your authentic apps or corrupt them. Such a person
could also sign and distribute apps under your identity that attack
other apps or the system itself, or corrupt or steal user data.
Your private key is required for signing all future versions of your
app. If you lose or misplace your key, you will not be able to publish
updates to your existing app. You cannot regenerate a previously
generated key.
Your reputation as a developer entity depends on your securing your
private key properly, at all times, until the key is expired. Here are
some tips for keeping your key secure:
Select strong passwords for the keystore and key.
Do not give or lend anyone your private key, and do not let unauthorized persons know your keystore and key passwords.
Keep the keystore file containing your private key in a safe, secure place.
In general, if you follow common-sense precautions when generating,
using, and storing your key, it will remain secure.
MD5, SHA1, SHA256 - different digests ( result of hash-function ) and cannot be used to restore your keystore.
Related
I'm trying to understand how java jar signing works at a high level. I know how to sign a jar, but I'm not sure how it works in terms of the validity of the key and when it needs renewed.
You included the keystore in your project and you give it the username and password ,etc. So if your key is valid for say, one more month. After that month, you go and renew it. Do you have to change the keystore in your project? What happens to JAR files that you built while the key was valid? Do they become invalid if you don't renew your key? How do machines that run your application verify the key? What if they are never online?
Thanks!
In desktop Java there exists a sun.security.mscapi.SunMSCAPI cryptoprovider that we can use with KeyStore to access Windows system certificates stores.
I know that there are similar stores on Android, but I can't find a way to manage these stores (list, add, delete certificates).
What I found is:
1) use KeyChain, but this requires additional interaction with user via Activities;
2) use KeyStore like on desktop and load storage files directly, but a path to these files isn't constant on all devices.
Are are any other approaches that I'm not aware of?
KeyChain is a relatively new addition. Its only available from API 14 (Ice Cream Sandwich) and higher. Nicolay Elenkov has a good blog entry on it at Using the ICS KeyChain API.
KeyStore is an even newer addition. Its only available on API 18 (Jelly Bean MR2) and higher. Nicolay Elenkov has a another good blog entry on it at Credential storage enhancements in Android 4.3.
You might also be interested in Unifying Key Store Access in ICS from the Android Developer's Blog. It tells us the KeyStore has been around since API 4 (Donut), but only the system could use it and it was only used for VPN secrets (Wifi was added later).
The user certificate store was kind of broken until recently. To remove a certificate from the store, you had to delete the entire store (even the certificates and private keys you wanted to keep). See User key/cert management in ICS.
The system's certificate store used to be stored in ROM. That changed after the Diginotar failure because Android had to build new images to remove the compromised Diginotar root. Given that so many carriers don't support their devices, there's literally millions (perhaps billions) of defective devices still out there.
If you want something that appeals to the largest selection of Android devices, then you probably need to use your own store. Perhaps a Java Keystore or SQLciper would be a good choice. Just be sure the database is encrypted with a key that derives from something the user inputs (like a secret). Combine the user's secret with a random value stored on the file system in your sandbox or KeyStore for maximum effect.
If you don't take the user's input, then you hit the "Unattended Key Storage" problem. And that's a problem without a solution. See, for example, Peter Guttman's Engineering Security.
How exactly SQLCipher for Android Application works?
http://sqlcipher.net/design/
As i understood it all depends on PRAGMA key and this key should be saved on app, maybe in binary.
However this is insecure as alomst everyone could decompile .apk file on rooted phone.
Maybe i missed something ?
Thank you.
As i understood it all depends on PRAGMA key and this key should be saved on app, maybe in binary.
No.
Maybe i missed something ?
The key comes from the user, in the form of a passphrase that the user types in. In SQLCipher for Android, this passphrase is passed to methods like getReadableDatabase() on the revised version of SQLiteOpenHelper.
Yes, securing the key is the tricky part. Ideally it's (partly) supplied by a password the user enters when signing on to the app, but that isn't always ideal, so sometimes you have to resort to the much-maligned "security by obscurity" approach and assemble the key from bits and pieces stashed here and there.
The SQLCipher team universally recommends against embedding a fixed key in an application binary. No matter how creative an application is about obscuring an embedded key, a sufficiently determined attacker will be able to extract it from the application package and open a database.
Unfortunately some applications still choose to use SQLCipher with embedded keys as a rudimentary form of DRM, i.e. by making it difficult for casual users to view data. However, this does not provide any substantial amount of security.
If you need to protect sensitive data the best approach is to use a key derived from a strong passphrase entered by the user. SQLCipher provides strong key derivation automatically, so all you need to do is provide the user passphrase through PRAGMA key or one of the equivalent keying mechanisms provided in SQLCipher wrapper libraries.
I generate key form secureRandom and then save key on KeyStore (BKS).
For KeyStore i generate password using: random, user info, device info and password.
I am working on a Java RCP application. A user needs to authenticate himself with his SmartCard to get access to the application. Inside this, he can open/save files which need to be stored encrypted.
Currently, I'm using a password-based AES encryption with a hard-coded password.
This is obviously not secure, so I need a different approach to encrypt/decrypt files.
What arouses this problem is that there are a few requirements to be met:
no guaranteed network connection (must be usable in offline-mode)
multiple users must have access to the files (so no public/private key encryption)
there should not be one "master"-key used for all files
Edit:
I doesn't need to have a very high level of security. It should just be a little bit harder for an attacker to get the key as to just open the distributed JAR file and get the key in plain text.
Any hints would be appreciated.
For each file, create a new key. Encrypt the file with that key (using AES).
Then, for each user that is allowed to read the file, encrypt the new key with their public key (one that corresponds to a private key on their smart card). Store these encrypted keys with the file.
When a user wants to read a file, the software uses his smart card to recover the content encryption key used for the file.
The file format could use PKCS #7's Cryptographic Message Syntax or OpenPGP.
Caveat: I am not well-versed in security and this is just something that crossed my mind.
As a suggestion, make the password for each file be a hash containing a known salt that is randomly generated for each file, and a single passphrase that is encrypted individually for each user. You can safely store the random salts locally, because these are not the key to the file, and no user knows the passphrase to unlock the file. By encrypting and signing the passphrase with public key encryption, you can authenticate users and control access on a per-user, per-file basis.
This way, you could use public key encryption from each user to deliver the passphrase, which is not stored anywhere in the system, secure the files independently of each other of each other, and not be dependent on outside sources.
What is the point of signing your code like Java's jars when everyone can do it with jarsigner?
How does it provide security?
The point of signing a JAR file is to verify that it has not been tampered with. Once a jar file is signed you can verify that this file hasn't been modified by someone else. This ensures that the file originates from the person that originally signed it. If someone has modified the file in-between the signature verification process will fail. You may check this article for more details on how public key cryptography could be used to perform digital signature.
When you sign a jar file you can show that it was you that signed it and not someone else.
It's the same idea when you sign a document - only you can write your signature. Other people can sign it, but they'll sign it with their signature, not yours.
With hand-written signatures a skilled forger can learn to copy your signature. With digital signatures it is much more difficult to make a copy because you need to get that person's private key. Without the private key you cannot make a signature that looks like theirs.
Signing a jar ties the contents back to a particular certificate. So what is that certificate proving?
If the private key for the certificate has been stolen, then not very much. There are tamper-proof devices for keeping private keys. However, often private keys often lie about on developer machines. Those machines are probably not well protected.
A certificate may itself be signed by a well known Certificate Authority (CA). So the end-user has some confidence that content has the claimed origin. The amount of verification that the certificate key holder is who they claim to be varies. This has led to a race-to-the-bottom where CAs simplify procedures to offer lower prices.
Even for unverified certificates, different content signed with the same certificate shows a common origin. So if you make a decision to trust a certificate, you can receive more content from the same origin without trusting anyone else.