I have an app built on java, and a server built on vb.net
I'm using https to communicate between server and client
I also encrypt my post data using AES encryption
My question is how can secure my key and iv used in AES , so if someone decompile the apk he wont be able to decrypt and encrypt the data
Anyone who knows please provid an example, especially for client side
Have a look at http://truelicense.net/xref/net/truelicense/obfuscate/ObfuscatedString.html
It can hide your key from being shown as plain text when the apk file is decompiled.
But using it just adds more security layer to your app, some guys with strong reverse engineer knowledge still can figure out how to de-obsfucate your key.
Related
I am using JWT for authentication. I use a signingKey to encode my token. I want to store the signingKey in a safe place on the client side (avoid hard coding it).
I was hoping to use android key store for that; but so far, I have only managed to create a key store using the JDK keytool to sign my app.
My question is: is there any way I can store a key inside the key store associated with my app, prior to its deployment on the device so that I can retrieve the key inside the app and use it to sign the JWT?
If not, what are my other options?
I developing on Xamarin. My backend is ASP .Net, deployed on Azure.
I don't know how to do it using a key store inside the App. But I have done it by storing it inside a JAR/.SO file. This gets obfuscated inside the App and is not available via reverse engineering.
Though this method solves only reverse engineering problem, the best solution would be to do with the server to avoid the network interception problem
I have a PKCS#11 library that contacts with the vendor's smart card. The low level details are not provided and I'm not interested in them either.
BTW the smart card has no internal certificate associated with it, its just a dumb smart card with a private key store.
So my question is:
What kind of code should I write to obtain a certificate from the PKCS#11 library, or do I need to write such code? does PKCS#11 supports exporting certificates?(I heard openssl supports using 3rd party PKCS#11 libraries. Can I use that to export a certificate from a smart card?)
If the answer to previous question is yes, in what kind of format is the certificate created? What kind of conversions should I to do in order to convert the raw created certificate into office supported format certificate?
and the last question is how to apply that certificate into microsoft office(2013) in order to digitally sign documents? It looks like that office itself doesn't like internal certificates and it keeps requesting us to get one from verisign (?) what's wrong here and how can I force office to use my own created certificate using the aforementioned method?
PKCS#11 interface lets you read ("export") the certificate from the hardware. However you need not just a certificate, but also a private key. Most hardware devices won't let you export a private key. PKCS#11 has a set of functions which let you perform cryptographic operations using private keys stored in the hardware, but not to export those keys.
The certificate is usually exported in native DER format, which can later be put to the PFX file. However without a private key it doesn't make sense.
Unfortunately I don't know what MS Office expects. I assume that Office in your case accepts only certificates which can be validated up to the trusted root certificate.
I have a web server that creates a QR code which is [username] + a md5 hash of [username][password].
Where [username] is the user logged in at the time.
Where [password] is a system password set by me and common to web server and the apps.
My Android/iPhone/BlackBerry/Windows app will scan this QR code and use the [username] provided in the QR code to hash with [password] which will tell me that the QR code came from my server.
Obviously if someone were to get hold of [password] then they could create QR codes that did not come from my web server. So is there anyway to safely store [password] in my app or could someone decompile the .apk and find it in classes.dex?
You can obfuscate the password somehow, but ultimately this is only security through obscurity. Someone who wanted to could certainly reverse engineer it.
You probably want to look at public key cryptography to avoid this - even if someone gets access to the public key, they still won't be able to use it to impersonate your server.
No.
If someone is sufficiently motivated, they will be able to reverse engineer a hard-coded password.
Im not sure about the other platforms, but if you put your password hardcoded in plaintext on android they would get it really easily. Other platforms might require more advanced methods. You can hash the password with some more advanced hashing algorithm so that they don't get the original password, but from what you said you don't want them making "fake" QR codes.
The short answer is no, because everything can be cracked somehow if it is on client side.
I'm writing an iPhone app that integrates with third party APIs. These APIs use OAuth (key/secret specific to my app not per user) in order to authenticate which app the request is being made in behalf of.
Is it secure (or how secure) is it to simply put the key/secret in code? Can this sort of data be reverse-engineered? Is there a better way to go about including this data in a project?
There is no place on the iPhone to hide data. A user with a jailbroken iPhone has more control over the device than any developer. If possible you should setup a web service such as a REST or SOAP service to take care of these OAuth transactions on behalf of the client.
As Rook said earlier, there is no way to hide your data in iPhone. But you can make hacker job so difficult. I just done a work around for the same issue.
Put oAuth key information in PLIST
Mannually I encrypt this PLIST by using AES key and I got encrypted "CIPHER TEXT"
Modify the AES key by appending characters in between with your own logic. Since it required at runtime to decrypt the plist
Add this modified key with plist "CIPHER TEXT" and store this value in New plist.
Remove old plist which has oAuth information
Now you have only one plist which has encrypted value with modified KEY
Advantage:
Hacking is so difficult since hacker don't have a proper cipher text in plist
To hack this code they should know to separate Modified AES key from Cipher text.
Thou they found Modified AES key, they don't have any clue about the appending algorithm, here i simple used EVEN position of the character, but you can't modify this and you can take 3rd or 4th position of the character. Which is actually will differ for each developer
for more information please visit below link;
https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication
I'd suggest looking into the Keychain services provided by Apple
http://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html
I would like to encrypt a string with AES 256 on the iPhone but have not found much via google. What I am trying to do is post some data to a web site as part of a game I am creating, but I do not want the user to be able to cheat by seeing how it is posted because it is plain text. So I want to post one encrypted string to my php page (ala www.test.com/test.php?encrypted= etc...) and then the php script will decrypt it and do what it needs to if it is valid.
You can just use the CryptoHelper which is adopted by CyrptoExercise Sample Project
A much easier approach here would be to use an HTTPS POST, which would give you similar protections with far less code, though there are still difficulties for solving the problem you're attacking. The kind of solution you're describing generally requires some kind of shared secret, and it's very hard to protect code using a shared secret for long. You may find these posts helpful:
Machine ID for Mac
Store an encryption key in Keychain while application installation process
Obfuscating Cocoa
Still, HTTPS is probably a much better solution than AES here.
Check out this site: http://iphonedevelopment.blogspot.com/2009/02/strong-encryption-for-cocoa-cocoa-touch.html