i have developed Java ME game and now i want to upload it to some of the sites for mobile games. After i finished it, i began to read papers for the producing the final .jar file and .jad file . I mean things like pre-verification , obfuscation , and signing with certificate. My question is specifiaclly for these certificates. If i upload my game and it is not certified ( it is not signed with certificate), will people install it on their phones? I have to mention that i think that i do NOT use some specific java ME api that require an app to be signed in order to used by the phone(I have read that one such api is httpconnection api - well, my game does not use such kind of api). The only thing that i doubt is the usage of RecordStore to store some information, but i think the java me RecordStore does not require the midlets to be signed. Anyway, i will ask in short - if my game is not signed , will people install it on their phone at all? (Just to mention, that the only thing that my game does in general is : paint, re-paint the screen , take the users input from keys, touch screen and use of RecordStore, nothing supernatural for phone game).
Thanks
The only thing signing does for you, is to remove the security popups you'll otherwise encounter whenever the app tries to access e.g. camera, sms, internet connection or filesystem.
No, you don't need to sign your game, and yes people will install it whether it's signed or not.
Signing is Compulsory for .sis and .sisx files.
J2me games Don't require signing.
Related
I'm currently assessing the pros and cons of going native vs. PhoneGap for an app I have in mind, and thus far, PhoneGap seems to be the ideal option since most of the data processing will be done on the server-side, while the app will merely be a means to get inputs from the user.
But I've been reading a lot about how all the PhoneGap .html and .js files would be easily accessible on a rooted/jailbroken phone. My concern is that my app will be using a couple of third party APIs, particularly Last.fm and Parse. Both these APIs come with an API secret. Would this not cause a security concern? While the maximum damage one could inflict with my Last.fm API secret key would be to exhaust the API limits, with Parse, it could be much more serious, especially if I plan to store user logins, passwords, emails etc. Anyone could simply grab my Parse Application ID and JavaScript Key and start querying away on Parse (and possibly (but not probably) a competitor or a troll (more likely) could push up the requests/second from my Application ID so that I end up with a big, fat US $10,000 bill).
Are there any methods to protect/encrypt/obfuscate these API secret keys while developing apps in PhoneGap? Does this problem go away if you go native?
First of all, I think the security issues you mention are not related to Phonegap only, same problems exist for native apps as well. I admit, it is harder to find these keys in native apps, but it's doable.
On a side note, both Android apk and Apple ipa files are actually zip archives, so you don't need a rooted phone to open up and peek inside. You can already do it for all the apps (not only Phonegap but native ones), open the archive, see the resources. But in native apps, you have a binary executable instead of html/js files. That's why it's not easy to figure out the data (keys), and app logic inside.
One approach is to implement a special scheme that will encrypt your js files during packaging (development), distribute it with the app and decrypt during runtime. It is totally possible (we did it in a project successfully), your Phonegap app becomes as difficult to hack as native apps. Note that I am not saying impossible, because you still have the problem of hiding the decryption key somewhere in your code/resources. Beware though, writing such a framework is not easy and requires some modification to Phonegap source code as well.
I think the safest solution to hide keys for Parse, etc. is to use your own server, implement server to server authentication and just pass a token to your client for client-server communication. In all other cases, you have to send the keys with the app, and however you hide it, there will be some guy who will find a way to unhide it.
I'm doing a hobby project Windows 8 app in WinJS. As I'm calling an external api, which requires an api key and oauth authentication, I've got a number of keys that I need to keep "secret".
I've seen places around the web with detailed descriptions on how to get access to and also modify the source code for WinJs (and C#) apps on your computer. But I think those were in the beta/preview time frame?
My Google skills don't seem to be able to tell me if this has been fixed since, does anyone know?
If it wasn't fixed, how do people handle these situations?
Any tips and suggestions welcome :)
You have a couple options here.
Integrate Azure Mobile Services and have it do the oAuth if possible. Your keys remain secret in the cloud.
Store the main key encrypted in your WinJs application. The secret then is also encrypted and stored locally. I use https://github.com/cauld/winjs-oauth-for-twitter and have a slight revision that when I get the key back I store it in the credential manager.
Any local application compiled from any computer language can be tampered with, all you need is a debugger. If you encrypt everything I in theory can just load up a debugger, attach to the http stack library and watch the data go out (excluding even easier techniques like Fiddler to watch this data) and extract whatever I want - fairly easily. So the question is what are you trying to prevent?
If your app could be facilitated to launch a man-in-the-middle attack, you should not keep confidential data in plain form for a long time, in memory or on disk. Also, storing encrypted data locally, alongside with the algorithm and the algorithm key/hash is a recipe for security incidents.
There is no silver bullet to protect your code or data from probing by the end user (or someone who has physical access to the end user's machine), see the amount of game save editors and game trainers out there. Don't put your business logic or important data (e.g. in-app purchases) in plain text or similar, at least add some obfuscation
I came across this line from the Nokia dev site. It seems to suggest that there are two ways of getting rid of those annoying confirmation messages when accessing protected services in j2me. Does anybody have any clue as to what might be the other method apart form signing?
"This document describes how to code sign a Java ME app using Thawte. This is one of two mechanisms for avoiding security messages when accessing secured APIs."
http://www.developer.nokia.com/Community/Wiki/Thawte_signing_for_Java_ME
Those Messages are because of your Application is not Signed with the required certificates.
Please look at to my answer here.
Not everyone can access the all API's of the Phone. To give a security to phone, Nokia has put those restrictions. Otherwise it may easy to create Mobile Virus too like computer virus.
When I am sending sms via j2me application, before message sent it appears question for can I use internet to sent message. Is it possible to exit this question to not appear?
This is happening because you Accessing HTTP & SMS API. For using such API you need to signed your Java ME Application. For Signed a the Java ME Application, you need to purchase Signing Certificate from VeriSign or Thawte Site by paying the Fees.
Plesae visit this link
For VeriSign's certificate, they costs 20K per certificate.
I think you can skip the prompt but your application must be signed. However, even if your application is signed, on some devices, the prompt will still appear once. This usually (or always) occurs on the session's first use of the Wireless Messaging API. This happens because the access to this API is set to something like "Ask first time."
If your app is signed, you can manually set the access to the wireless network settings to (something like) "Always allow." If it is set to (something like) this, the prompt will not appear.
For apps that are not signed, the option "Always allow" is not available. However, on most devices, the next best option is available: "Ask first time."
Well, the bad thing is, you are going to set it manually. The good thing, however, is that you are not going spend so much money just to set it to "Ask first time." :D
J2ME by the platform design have the drawbacks in which users of the applications are asked to select yes or no for any attempt to use any of the secure API's. Some devices gives this alerts in such a way which will make the end user to think if he should go ahead or stop it there. By digitally signing the application, one can reduce the alerts to levels depending on the device KVM implementation and the number of secure APIs in use.
In some device having Symbian OS Feature Pack 1, the prompts continue even if the code is signed.
This behavior of J2ME makes the applications less developer friendly and less user friendly. I think this is a wrong strategy and model adopted by SUN. There is some thing called Verified by Java in which you can get your application signed using a certificate which will make the application work seamlessly and without prompts in the end user device but unfortunately the process of getting that certification is expensive and not practical. The only advantage of J2ME platform is that it allows less chances of virus or malware code to be executed on the end user device. I think the trade off between security and ease of user use is not worked well and that is the reason we don't see very good apps in J2ME.
In contrast, Android for example, lets the user see all the permissions prior to installation of the app and the user is not bothered at run time when those secure API are used. That is the reason we see millions of apps there and not in J2ME. We can always say this approach had led to many malware types of applications in the end android user device but that is how it goes, people need to have smooth apps running and are happy with them.
How do you secured a key into your iPhone application?
I have an API key that is used by the client application, and do not want anyone to see it, only the application should be able to read it.
1) how do I safely store this in my application? storing it into a variable? is good enough?
2) What happens if someone decrypts my application? (Is that possible?)
There's a lot of questions here so let me answer one at a time:
How do you secured a key into your iPhone application?
I assume that you are trying to secure it from the user of your application. This is impossible unless you are using a trusted computing platform, ie. a platform that can be trusted to not obey orders from its owner (sometimes called treacherous computing for that reason). iPhone is not such a platform to my knowledge.
I have an API key that is used by the client application, and do not want anyone to see it, only the application should be able to read it.
If your application can read it then the owner of the platform that your application runs on can read it as well. (The exception would be a trusted computing platform - see above.)
how do I safely store this in my application?
You can't.
storing it into a variable?
You might.
is good enough?
No.
What happens if someone decrypts my application?
Then he gets your key.
Is that possible?
Yes.
If you don't want your users to know your key then don't give it to them in the first place. Set up a proxy server that your application would connect to and keep your secrets there.
There's an old saying that every secret has to be treated like a public knowledge unless it's known by no more than two people. This applies to software too.
Consider storing the key in the iPhone's keychain repository. Take a look at the Apple provided keychain sample app here:
http://developer.apple.com/library/ios/#samplecode/GenericKeychain/Introduction/Intro.html
Hope this helped. Good Luck.
I agree with Greg Thompson, Apple recommends the use of the keychain to store secure data such as credentials.
By the other hand there is a couple of articles around the web that says that the keychain is no longer "the safer zone", because some people were able to decode its data (and pretty quick).
With iOs 4.0 and later, some improvements about security where made, that is called Data Protection (you can google it like: iOs data protection).. if you are interested in this topic, you'll find the Session 209 - Securing Application Data from WWDC 2010 Session Videos very interesting ... You can get this video for free via iTunes store - iTunes U
Hope this helps