Im implementing the algorithm AES in my mobile app with a 128 bit key, now im wondering how to actually test if the encryption works and how secure is it, is there a way that i can simulate an attack to my application (maybe a free software)? so i can see if its secure enough.
Related
How would someone go about preventing MITM type attacks against API secrets/ API keys?
How does facebook/ instagram protect their users against MITM type hacks?
Do they even protect the users? Or they assume that any possible attacks should be shouldered by users?
Some Context on my Answer
I assume that your question is in the context of mobile apps, thus my answer will show how to protect against a MitM attack for APIs serving mobile apps and how it can be bypassed.
Your Facebook/Instagram Related Questions
How does facebook/ instagram protect their users against MITM type hacks?
Do they even protect the users? Or they assume that any possible attacks should be shouldered by users?
This questions are best answered by an insider at Facebook/Instagram or from a security researcher that have done extensive work on their mobile apps and APIs.
Sorry for not being able to elucidate you here.
Preventing MitM Attacks
How would someone go about preventing MITM type attacks against API secrets/ API keys?
This one I am able to help you with and the quick reply its by using certificate pinning against the certificate public key, and we will go in more detail below.
In a first instance you will want to secure the HTTPS communication channel by configuring the mobile app to only establish a connection with the API, during the TLS handshake, if it presents the certificate issued for its domain and that is known and trusted by the mobile app, ignoring any other that may still be valid as per validation against the certificate trust store of the device. I go into more detail about it and how to implement it on the article I wrote Securing HTTPS with Certificate Pinning:
In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.
In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.
What to pin?
From the same article I will quote:
The easiest way to pin is to use the server’s public key or the hash of that public key, The hashed public key is the most flexible and maintainable approach since it allows certificates to be rotated in the server, by signing the new one with the same public key. Thus the mobile app does not have to be updated with a new pin because the hash for the public key of the new certificate will continue to match the pin provided in the network security config file. We will see an example of this later when we talk about how to setup certificate pinning.
Implementing Static Certificate Pinning
The easiest and quick way you can go about implementing static certificate pinning in a mobile app is by using the Mobile Certificate Pinning Generator that accepts a list of domains you want to pin against and generates for you the correct certificate pinning configurations to use on Android and iOS.
Give it a list of domains to pin:
And the tool generates for you the Android configuration:
And the iOS configuration too:
The tool even as instructions how to go about adding the configurations to your mobile app, that you can find below the certificate pinning configuration box. They also provide an hands on example Pin Test App for Android and for iOS that are a step by step tutorial.
Bypass Certificate Pinning
It's important that any developer that decides to implement certificate pinning in their mobile apps also understands how it can be bypassed in order to learn the threat model and evaluate if further protections are needed to prevent certificate pinning bypass.
I wrote two articles on how to bypass certificate pinning on Android where you can learn in one of them how to do it by extracting, modifying and repackaging the APK, while in the other article you learn how to use the Frida instrumentation framework to hook at runtime into the mobile app in order to bypass certificate pinning:
Bypassing Certificate Pinning on Android via APK
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Summary
Despite being possible to bypass certificate pinning I still strongly recommend you to implement it in your mobile app, because it reduces a lot the attack surface of your mobile app.
Being aware of how certificate pinning can be bypassed gives you the insights to decide if further protections are needed to be in place. Dynamic certificate pinning and Runtime Application Self-Protection(RASP) may be the next steps to take in your security ladder.
We are developing a banking mobile application using MobileFirst V7.1. As it is a banking mobile application security matters more the sensitive data from mobile client to MobileFirst server trasnferred securely. hence the data should be encrypted from the mobile client/App side and sent to the MobileFirst Server and at the server side we have to decrypt the data and call the backend webservice. As per the client requirement the following are the steps to be implemented for encryption logic:
Step 1: Generate a symmetric key
A 32 bit random key will be generated
Step 2: Encrypt the data with this key, using a symmetric algorithm like AES.
The sensitive data is encrypted with the above generated key using AES algorithm
Step 3: Encrypt the symmetric key with the public key, using a asymmetric algorithm like RSA.
The key (32 bit random key generated in step1 an used for encryption of sensitive data in step2) is encrypted using the asymmetric algorithm RSA public key
Step 4: Bundle the encrypted symmetric key with the encrypted data
Bundle both the encrypted sensitive data and encrypted random key in an object and sent it to the server. At the worklight server end, from step4 to step1 is performed in reverse to decrypt and get the original data
The problem is I'm able to achieve the encryption logic from step1 to stpe4 at the application end, but when I use the same RSA alogorithm java script libraries in the MobileFirst HTTP adapter side to decrypt the data, I'm getting many errors stating that "window" is undefined, "navigator" is undefined. The RSA javascript libraries consists of navigator, window, at the mobilefirst adapter javascript file these navigaotr or window is unavailable, hence I'm getting this errors and I'm unable to move forward. Can anyone please help me to resolve this or help me in implementing the Enctyprtion logic as mentioned in the above step1 to step4 in my MobileFirst application.
Thanks in adavance.
Check this older response form stackoverflow:
I don't see issues on encrypting you adapter request/response payload(the data you send and receive inside of an adapter call).
Worklight adapter calls are not encrypted (WL.Client.invokeProcedure)
Although, if you encrypt the entire request(or response) used by this will confuse the adapter Client/Server internal communication protocol.
If you want extra protection on on the transport layer(Like HTTP/HTTPS) and maybe an extra layer. I would check if in your case, a IBM DataPower would not what you are searching for: https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Appliances
Application Layer: https://en.wikipedia.org/wiki/Application_layer
You can use also the adapter mash up technic at the adapter calls in a single adapter endpoint to prevent unwanted eyes to try ton reverse engineer this call by its name, and this 1st adapter can decrypt the payload at the server-side and send to the wanted adapter internally(inside the server-side).
https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/adapters/advanced-adapter-usage-mashup/
I hope this helps,
You have to write own code for encryption or decryption, I think you are using third party library to do encryption/decryption which is browser based. As worklight adpater does not recognize window/navigator.
I am using cryptography concepts in my application. Some Encryption and decryption techniques and salt values are hard coded and IV values are using those techniques. Before I publish the app I need to obfuscate to my code. I am using XCode 6.2 version with updated OS. Please share with me techniques about how to do it.
Neither "decryption techniques " nor iv need to be kept secret, only the encryption key. Good security requires using proven methods and cryptographic primitives not secret methods. Developer created cryptographic methods are usually insecure and lack peer review for flaws, the standard methods have been well researched and vetted for security flaws.
Shipping with the key embedded in the code is a problem, the key should be randomly generated (or in some similar process) at first-run and stored in the Keychain.
If SSL is not acceptable for my app to communicate with the client, how should I encrypt the traffic? I need something fast (so public key algorithms are out of question).
I was thinking about One Time Password, but the problem is that I can not store a very long key on the mobile app because of app size restrictions. What would you recommend?
How do you know that SSL isn't acceptably fast? Have you benchmarked it? As David said, SSL only uses public-key cryptography for the setup and to establish a shared secret, which is then used as the key to quick symmetric algorithms. So before you reject SSL, you should actually test it first.
I am developing and application in vb.net winxp+ (windows xp upwards). The application has to receive backup data from clients software located at different pc over the Internet. but am concerned about security of this application on the Internet.
what would be the best way to implement security in vb.net 2008 to make sure that the data is not sniffed or interfere with?
am thinking of encrypting the data before sending, saving it that way until it need to be viewed before decrypting.
what type of encryption would you suggest?
Is there any other way you would suggest this data be sent?
First of all your Server Application has to be a Windows Service. I imagine that your server will be always up, so a Windows Service is the right thing to implement.
Here you can find a reference on how to implement a Windows Service using .NET languages (it's very easy).
Then to secure the channel you have to do a choice about the type of encryption you want to use:
Symmetric: AES, 3DES, BLOWFISH, etc.
etc.
Asymmetric: SSL or your home
made protocol
The symmetric option (here is an example) has an hard key management because you have to store all the client's keys onto the server. Or you can use the same key, but it's not secure because you have to protect very well the client key. If an attacker gets the client's key, whole security infrastructure is in the hands of the enemy.
But you can have a different symmetric key for every client and the server chooses the right one. Anyway you have to protect the client's code and key (obfuscation and so on)
The asymmetric option (here is an example) is the best choice for me because you can have:
client authentication to the server
(the server has all the client's
public key and verify the sign)
server authentication to the client
(the client have the server's public
key)
channel encryption (channel is
encrypted with the symmetric session
key handshaked by the clients and
server through the public and private key)
The best and well-known protocol implementing the last one is SSL. You have to find APIs that implement it or you have to do by yourself (it's very hard to implement without bugs and security concerns).
Remember that you need certificate for SSL communications. X509 made via OpenSSL are good for your requirements and are easy to create.
There are two different things you should consider here.
Is it a requirement that the backup data are encrypted on the server, in which case clients should encrypt data using a symmetric cipher (e.g. AES) before doing the transfer.
For the transfer itself, SSL (https) would be a solid solution, with server-only authentication.