payment by debit.
Connect to bank backend system.
What I need to know is how the server know that the client that request is the authentication (authorize) one.
Main Topics
Browse All TopicsWe're building mobile payment solution using J2ME in client side.
How we can we create signature in client side so the server have no doubt that the client is the authorize one.
Please advise.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
its very simple.
when you use http connection to conect to your server, pass the parameter in url string as follows
http://myserver?athenticat
where athentication is a parameter.
now about authentication, when user submits the money/transaction he has made, return a parameter to your mobile client, where tht mobile/client will save this information in RMS (mobile database) and when he needs to conect to server, he will add that information to server url.
hope you got ma point.
kind regards,
qasitouch.
what we need is, each client has unique ID, so when client A request to server, the server could verify that the request come from client A, not from other client that acts as client A.
Then the message can be encrypted by the unique ID as key.
My question is,
- is it possible that we could store the ID in handset or app client without being cracked?
- if not, how will be the best way?
yeh,
i have already told you that you can store your id in mobile.
If you are using J2ME, read RMS, USE RMS (mobile database) will store your id.
read this to know how to use RMS using j2me:
http://www.microjava.com/a
now when the user login to your service, the application will read the id from the RMS and then send to your service for verification and so on.
and i think your problem is solved now :)
Kind Regards,
qasitouch.
I wouldn't be too sure about that.
I'm not certain of the best way to progress with this, so I'm watching this thread with interest.
However, I can tell you that RMS record stores are not secure. You need to be extremely careful about what you are going to store in one if this is for a secure banking application.
Anyone with a basic emulator and a bit of knowledge would be able to download the application and view the contents of the record store. I'm sure that even encrypting the data wouldn't be all that helpful in stopping a determined hacker. And let's face it, banking applications will attract them.
Jim.
dear, i know all about it too. but u'll have to store it into RMS
as i said before, use some encoding to store the data into RMS.
2nd you must use obfuscation, which will protect your code for certain level. proguard is the best obfuscatuion tool.
read this about obfuscation:
http://techwireless.wordpr
kind regards,
qasitouch.
Here are some thoughts and ideas:
Before allowing the MIDlet to be downloaded, you should perform as many checks as possible to ensure that you are dealing with a genuine client, eg.
1) Check that it is a mobile device that is requesting the download
2) Check the IP address of the request to ensure that it is from a known mobile network operator
3) Verify the user with a password/PIN
When you are convinced that you have a genuine client requesting the MIDlet:
1) Dynamically add a unique identifier to the JAD file (and, if possible for additional security, the JAR file).
2) Create a PIN for the account which should be communicated to the customer in a secure way (eg. post)
3) Digitally sign the MIDlet (this won't protect the value in the JAD file, but would protect it in the JAR)
4) Allow the client to download the app.
5) Consider the use of the MIDlet-Install-Notify attribute in the JAD file to try to confirm that the MIDlet has been successfully received and installed.
General:
1) Of course the MIDlet should be obfuscated.
2) All communication with the server should be encrypted (HTTPS or some other encryption)
3) When communicating with the server, the unique client ID should be backed up with the user-entered PIN.
Jim.
The solution given by gasitouch will not do you any good at all!! The solution is very primitive. The data traffic taht goes over HTTP is easily readable on the service provider end. Using simple encryption is insufficient again as it will not serve your purpose as you are looking at monetary transactions with MAJOR repercussions. And obfuscation of code is good, but you cannot afford to add the keys to the code - just imagine the headache when you need to modify it!!
Overall, chuck all the solutions given by gasitouch here, any banks that tries to get you system in place will REJECT it OUTRIGHT as it has security holes all over the place!!!
If you have got GPRS connectivity, then your safest bet would be to use HTTPS. That will result in your required level of data security between the mobile and the bank - but it will not resolve your problem of one user masquerading as another, i.e. you need something to uniquely identify different users.
I have already implemented a complete solution of this kind and it is live with certain banks (over SMS and HTTP)
If you are interested, get back to me!!
And again, do not try to follow the line of thought suggested by gasitouch, you will go in the wrong direction!!
No hard feelings gasitouch, but the solution will hit him in the long run!!
(edited for language -- Chaosian)
@keyurkarnik
CHILL DUDE
@ question
i still stick with my words and yeh https is better then the http, u can aslo do that. but you will have to use rms and do the same process as i said.
by obfuscating code , encripted data in RMS and using https you can achieve max. security.
2nd you can also encript your user-id to before transmiting to server, where on your server side use as you want to use, and send ack/nack according to user-id.
talking about security holes, its like that. no. check PAYPAL api for mobiles/wap. its also using https and url way for athentication. if its so un-secure, why the whole world trust on paypal. and i have used paypal for mobiles too.
anyways this is the most popular and most used and secure scenario used in J2ME and even i developed sevaral applications and user-athentication in this way.
kind Regards,
qasitouch.
Please keep the discussion in the thread. If you have clarifications or modifications to make to my suggestions I would be pleased to hear them, but taking the question private goes against the ethos of EE.
http://www.experts-exchang
Jim.
Business Accounts
Answer for Membership
by: qasitouchPosted on 2007-11-07 at 03:59:20ID: 20231271
what kind of payment ??
cradit card or anything else ?
please give me little detail about your problem, so i can give you exact answer.
Kind Regards,
qasitouch.