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.
Related
I am looking for a way to encrypt messages between client and server using the WCF. WCF offers a lot of built in security mechanisms to enrcypt traffic between client and server, but there seems to be nothing fitting my requirements.
I don't want to use certificates since they are too complicated, so don't suggest me to to use certificates please. I don't need confidentiality, so I though I'll go best using plain RSA.
I want real security, no hardcoded key or something. I was thinking about having a public/private keypair generated every time the server starts. Both keys will only be stored in RAM.
Then wen a client connects it should do exactly like SSL. Just as described here.
1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)
2.using that private/public key pair, exchange a common shared secret, e.g. an "encryption key" that will symmetrically encrypt your messages (and since it's symmetrical, the server can use the same key to decrypt the messages)
3.setup infrastructure on your client (e.g. a WCF extension called a behavior) to inspect the message before it goes out and encrypt it with your shared secret
That would be secure, wouldn't it?
Is there any existing solution to archive what I described? If not I'll create it on my own. Where do I start best? Which kind of WCF custom behaviour is the best to implement?
EDIT:
As this is NOT secure, I'll take the following approach:
When Installing the server component a new X509 certificate will be generated and automatially added to the cert store (of the server). The public part of this generated certificate will be dynamically included into the client setup. When running the client setup on the client machine the certificate will be installed into the trustet windows certificate store of the client.
So there's no extra work when installing the product and everything should be secure, just as we want it.
You've said you don't want to use certificates. I won't push certificate use on you, but one thing you are missing is that certificates serve a purpose.
A certificate proves that key you are negotiating an SSL connection with belongs to the entity you think it belongs to. If you have some way of ensuring this is the case without using certificates, by all means, use raw keys.
The problem is, in step 1:
1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)
How does the client know that the public key it received from the server wasn't intercepted by a man-in-the-middle and replaced with the MITM's key?
This is why certificates exist. If you don't want to use them, you have to come up with another way of solving this problem.
Do you have a small, well-known set of clients? Is it possible to preconfigure the server's public key on the client?
Alexandru Lungu has created an article on codeproject:
WCF Client Server Application with Custom Authentication, Authorization, Encryption and Compression
No, it would not be secure!
since there's no confidentiality, an attacker could do a men in the middle attack, and all the security is gone.
The only real secure way of encrypting messages between server and client IS to actually use digital certificates.
I'm sorry, the only two methods of providing secure communications are:
Use a public key infrastructure that includes a chain of trust relationships, a.k.a. certificates
or
Use a shared secret, a.k.a. a hardcoded key.
Nothing else addresses all of the known common attack vectors such as man-in-the-middle, replay attack, etc. That's the hard truth.
On the other hand I can offer you an alternative that may alleviate your problem somewhat: Use both.
Write a very, very simple web service whose only job is to generate symmetric keys. Publish this service via SSL. Require end user credential authentication in order to obtain a symmetric key.
Write the rest of your services without SSL but using the symmetric keys published via the first service.
That way your main app doesn't have to deal with the certificates.
I am implementing an app where I don't have a system requiring username and password. What I do require is a name and a phone number.
The scenario is like this:
1) user opens the app for the first time
2)app makes a request to my server and gets a unique UserKey
3)from now one any request the app makes to my REST service also has a signature. The signature is actually a SHA(UserKey:the data provided in the request Base64Encoded)
4)The server also performs the same hash to check the signature
Why I don't use SSH:
not willing to pay for the certificate
I don't need to send sensitive data like passwords, so I don't see the benefit of using it
I just need a simple way to call my own WCF REST services from own app
I understand that there is a flow of security at step2 when the UserKey comes in cleartext, but this happens only once when the app is first opened. How dangerous do you think this is?
What would you recommend? Is there any .NET library that could help me?
Actually, there are several problems with that approach. Suppose there's man-in-the-middle whenever you make a request to the server. By analyzing, for example, 100 sent packets he would recognize similar pattern with signature in your requests. Then he would forge his own request and add your signature. The server checks the hash - everything's alright, it's you and your unique user key. But it's not.
There's a notion of asymmetric keys in cryptography which currently is really popular and provides tough security service. Main concept is the following: server generates two keys - public and private; public key is used to encode texts; they can be decoded only with the use of private key, which is kept by the server in secure location. So server gives client the public key to encode his messages. It may be made double: client generates public key and gives it to the server. Then server generates keys and gives encoded with client's public key his own public key. This way it's almost impossible for man-in-the-middle to make an attack.
Better yet, since the problem is really common, you could use OAuth to authorize users on your website. It is secure, widely used (facebook, g+, twitter, you name them) and has implementations already in variety of languages.
Since you control both the application itself and the webservices, you can do this with SSL (which gets rid of the problems with your current approach) without paying for anything. You can create a self-signed certificate and install that on your webserver; configure the SSL context of your client application to only trust that one certificate. Then, create a client-side self-signed certificate and install that within your application. Set the server up to require mutually-authenticated SSL and only allow your self-signed certificate for access.
Done. You client will only talk to your legitimate server (so no one can spoof your server and trick the client in to talking to it) and your server will only talk to your legitimate clients (so no one can steal information, ID, etc). And it's all protected with the strong cryptography used within SSL.
If one way SSL is used (Server Certificate authentication) then data sent from client gets encrypted using Public key of the server certificate. So privacy protection is available for data sent from client. My questions are
Does this mean that in One way SSL data sent from Server to client is not encrypted and sent as plain text ?
For both server to client and client to server communications the data/message is not signed and so tamper protection or data integrity is not assured. Are there any other means to achieve data integrity while using SSL based transport security and not Message security options ?
One way SSL just means that the server does not validate the identity of the client. It has no effect on any of the other security properties of SSL.
While the SSL protocol is a bit complex, the basic gist of what happens is this: The client generates a random key, encrypts it so that only the server can decrypt it, and sends it to the server. The server and client now have a shared secret that can be used to encrypt and validate the communications in both directions.
The server has no idea of the client's identity, but otherwise, the encryption and message validation is two way.
Update:
1) Yes, encryption both ways is symmetric and uses a shared secret generated during session setup.
2) With a shared secret, message integrity is trivial to assure. You just ensure the message has a particular form. For example, I can prefix every message I send with a sequence number and append a checksum onto it before encryption. You decrypt it with the shared secret and validate the sequence number and checksum. How can an attacker substitute or modify the message without knowing the shared secret and still keep the sequence number and checksum intact?
In SSL, two things happen:
First, a session key is negotiated using something like the
Diffie-Hellman method. That generates a shared session key but never
transmits the key between parties.
Second, that session key is used in a normal symmetric encryption for
the duration of the connection.
SSL does use public/private in one way, because an X509 certificate is
used to identify at least one end of the connection. Those certs are
signed using an asymmetric key pair.
Extracted from How can SSL secure a two-way communication with only one key-pair?
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.
I would like to read the information a java application in firefox is sending to a website over an ssl connection.
I am using WireShark, and I believe that if I can somehow tell tell wireshark what encryption key firefox is using, then wireshark will be able to decrypt the ssl messages.
Then I will exactly what information this website is getting about my computer.
My apologies if the question is vague ... any pointers on where to start looking for clues would be appreciated.
Not really programming related.
However in order to do this you'll need the certificate for the site your application is connecting to, both the public and the private key parts - so if it's not a site you own then you'd not going to be able to do it. If you control the receiving web site then simply follow the instructions on the wireshark wiki.
Assuming that you're not trying to do this programmatically, but instead just want to view headers whilst debugging, you could use Charles:
http://www.charlesproxy.com/
There's a fair bit of information here about how to set it up to decrypt SSL traffic:
http://www.charlesproxy.com/documentation/using-charles/ssl-proxying/
The java application would encrypt all information with the server's public (SSL) certificate (at least as far as you are concerned). For all practical purposes the only way to decrypt this afterwards is to know the server's private key which you apparently do not have and therefore there is no way that you can decrypt it.
To answer your comment about whether to use your computer's private key:
If this is a "normal" SSL connection, the client (java app) will contact the server and receive its public key, verify it's valid (signed by a trusted CA) and then use it to negotiate a symmetric key that is used for encryption.
Public/Private keys work in a way that everything encrypted by one key can only be decrypted by the other - i.e. everything the Java app encrypts using the server's public key, can only be decrypted using the private key - which never leaves the server.
SSL/TLS supports client certificates, in which the Java app can have its own key pair and use its private key to sign the contents in order to verify the authenticity of itself. However even if the Java app does that (doubtful) it does not help as the data will still be encrypted so that only the server can decrypt it.
Background reading: http://en.wikipedia.org/wiki/Transport_Layer_Security and http://en.wikipedia.org/wiki/Public-key_cryptography