The handset maker bypassed the Qualcomm/BREW certification or authentication process. The phone only runs on the Sprint Network. I cannot access developer mode because I lack the required signature. I registered with BREW dev team, etc. Since the phone was never certified through BREW, I'm being told that I cannot obtain the signature from BREW. Can I obtain this signature from Sprint or the Hand-Set maker? Do they have to give it to me or charge me for it? Any other ideas would be appreciated.
Kevin
I think they could but they won't. Or even Sprint might not have the ability, they might only have signing keys given to them from BREW/Qualcomm for their use only. Either way, I recommend you get another phone, and pick one which has as many "grandfathered" devices as possible, this will reduce testing if you ever decide to release your app on one of the stores.
Related
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.
After the Sony PSN debacle, I am trying to find examples of secure hardware tethering to a network. There are two use cases in particular:
1- computer downloads a piece of software that then uniquely and securely labels it to a cloud service
2- a hardware manufacturer uniquely labels a hardware device that then negotiates membership on the network.
Given the fact that the hardware device might have to change (revoke or service enhancements) it feels like #2 becomes #1.
The broad outline is this:
- connect to the service via HTTPS to protect against man in the middle
- device generates a GUID and presents it via HTTPS to service
- service records GUID against account
- on success, service 'enables' device
But how do you protect the GUID so that it cannot be stolen?
I just wanted to comment here:
Sony's PSN issues started with horrible practices with regards to their QA environment.
First, they defaulted to trusting anything that was sent to those servers using their developers toolkit. The reason they did this was that the dev kit used to cost upwards of $10k US and therefore they thought anyone who paid that amount would be on the up and up. However, when they radically lowered the price things changed externally and they didn't account for it.
The second issue with PSN was that the security between QA and live was, well, weak at best and easily circumvented. My understanding is that you could send commands to live using QA credentials. Because QA credentials were used, all chargeable actions were approved without money changing hands and the actions were applied to live accounts. When several people told Sony about this they did nothing.
A third issue was a reliance on hardware based encryption keys. Even hardware encryption keys installed on the devices can be figured out.
Point is, Sony dug their own grave on it so I wouldn't use anything they did as a template for how to do things. Heck, a lot of their websites were open to SQL injection which in today's day and age should get you fired.
Another example here is the iPhone. Each iPhone has a unique identifier that installed apps can grab and send back across the network; similar to a serial number. Some apps use this ID to try and tie a particular device to a person. However, it's trivial to create ID's and broadcast them, so this hasn't worked out so well for the partners. Also Apple does not expose a way to ensure a given ID (UUID) is valid to app producers.
A third example is mobile phone carriers. They use a particular ID baked into your SIM card to identify your account in order to know who to bill when a call is made. This ID is verified whenever the phone checks in with the network. However, we're dealing with radio signals and any device that can broadcast a correct ID can gain access. Point is, honest people think that only AT&T approved devices can get on an AT&T network. Reality is, anything can but they are going to bill the owner of the particular ID...
That said, any software you have running on a remote device that is not under your direct control is likely to be hacked. The popularity of the device will increase the likelihood of it happening sooner rather than later.
Where do we go from here?
On a basic level you associate an ID with an account in your service. PSN, Apple and others have done this. When an ID is broadcast, you need to verify that it exists AND that it's tied to an active account. If both pass then you have two options: either perform the action requested OR request additional verification.
For any actions that require money to be spent, do the additional verification (usually some form of username/password), capture the funds, then perform the action. Go one step further and every time a bad login is entered, send an email to the user on file. Further, automatically send a receipt. These are typically done so that your honest users can tell when something is going on.
Anything else just let through.
Bearing in mind, of course, that QA credentials should NOT work in your Live environment. Those systems should not be tied to each other under any condition and, quite frankly, should even live on separate hardware. In other words, QA and Live should NOT share a login database.
The thing here is that you shouldn't care about the device itself; just the account. You can't control the device as it's out of your hands; heck you can't even be sure it hasn't been physically tampered with. (XBox has been fighting this one with people adding resistors or burning out certain components to get past physical security features).
So, IMHO, do a bit to keep honest people honest but overall don't worry about it. Now, you should transfer everything via SSL or someother encrypted connection between the device and your cloud so that you don't leak ID's to anyone that wants to grab them. This will help protect those honest people.
Further, you shouldn't have a direct way to query whether an ID is valid or not from the outside. This will make it a bit more difficult for a hacker to find existing valid IDs and take over accounts. If you want to get fancy you could honey pot those and track the hackers down in order to sue them into oblivion, but that takes time and resources companies don't normally have. Also you could log all of the requests that contained bad IDs and use that to track hackers down.
Note that even after the device has been "enabled" I still suggest you have two levels of authentication. The first is for simple actions like downloading free content; the second kicks in anytime there is a fee associated. Again, we're trying to protect your honest subscribers.
For the dishonest ones you will have to apply some statistical analysis on the transactions coming across. Things like the transaction rate can help identify bots that are running and allow you to kill their IDs. There are others but they'll be unique to your application.
This was long winded. But my point is:
You can't secure the ID or anything else you pass out.
You can't ensure the requests are coming from your devices or your own approved devices.
You better take actions to keep QA and production separate for those building software for these devices using your services.
You better take actions to protect your normal honest users.
Trust NOTHING.
Due to the above you should evaluate your business model so that you don't care what device was used and instead focus on the individual accounts themselves; which you do have control over.
I am not sure I entirely understand the question, but I think you want some sort of device to hold on to a GUID assigned to it by a web service, and you don't want someone finding out what that GUID is, correct?
If so, there isn't a lot you can do. You have already mentioned one option... using HTTPS during the assigning of the ID. That is a good start, but remember that anyone who has physical access to the device can do a lot of things to look up this ID.
In short, it is impossible to completely hide. Someone can always reverse engineer it. There are folks out there reading data right out of memory with hardware.
this is my first question so please be gentle...
I am working on a software which I would like to protect using some kind of licensing scheme.
A basic scheme would be to generate some "unique" key for a user. The user sends this key and a registration code when he wants to register the software and receives an activation code.
When the application runs it validates the activation code by comparing the "unique" key and a datablob received by decrypting the activation code.
This is fair and quite simple to implement, one can choose different crypto algorithms etc. however this scheme lacks two properties:
If the user manages to spoof hardware signature etc. to produce the same "unique" key on another computer he could use the same license data.
If the user decides to uninstall the application and wants to move it to another computer, there is nothing that prevents him from using the old license data again at the old computer and still obtaining new license data for the new installation.
Do you have any suggestions on how to resolve these issues?
One idea I had was to add some random data to the "unique" key, this random data would be stored in an obscure way, if the user deinstalls the application this random data would be removed, and some kind of hash with the previous random data and the license data would be generated which could be sent to me to verify that he really have uninstalled the application and made me sure that he wont be able to use the previous license data again since the random data had changed.
Over and out, for now...
EDIT:
I currently have a scheme that works, I should mention that the most common product is installed in an embedded enviroment where hardware-changes are very rare and if there is a hardware failure then most certain the machine is broken. But I could modify the hardware-key scheme to take into account and allow for some changes.
Also because of this the software will most likely not be run inside a VM, good point though and I haven't thought about that.
The application does not call out regularly, if a network connection is available the user gets the option to make a more automatic registration, otherwise he/she gets a registration key, enters it in the software and gets an installation ID which is provided to me, registration code + installation ID generates an activation key that the user gets from me which then unlocks the software.
What I am looking for is good/feasible solutions to the 2 points. Hardware spoofing, Revoking license keys i.e. to be sure the user can not use the same regcode+activationcode.
Thank you for all your feedback
It is not necessary to
First, you should make it clear what you're trying to protect. Apparently, you want to ensure that for each purchase of your application, there will only ever be one computer on which the application is installed and runnable.
You propose to use a hardware signature as part of each user's unique key. What happens if my hardware fails (e.g. my hard disk breaks)? I'm certainly not going to purchase your application if I can't go on using it after a hardware problem, so at a minimum you must be prepared to handle key change requests. You'd better respond fast, because if your application is important I want to minimize downtime. And I'm not inviting you to check that my hardware has failed, so you'll have to take my word for it. That means any user can get a free licenses from time to time by pretexting a hardware failure.
What about virtual machines? It's probably feasible to detect all currently existing virtual machine configuration, at the risk of a few false positives now and then. If you forbid virtual machines, how do you justify this to users? If you allow virtual machines, how do you prevent the user from making multiple copies of the whole VM? (This can happen even with physical machines, with hibernation).
Is the application going to call back to you every time it starts? I guess so, from your deinstallation scheme. That's a bandwidth and availabilty cost, and will also put off some users — not everyone is online, especially in sensitive environments. But then you don't need such a complex scheme: your server can keep track of how many copies of the application are running, though you do have to handle the case when the application doesn't terminate cleanly for any reason (application crash, OS crash, power failure, loss of connectivity...).
You don't discuss this in your question, but you have to protect the application executable, so that someone can't bypass the license check with a debugger.
Place your software into appliance hardware and put a padlock on the hardware. Ship the appliance to the customer.
If you believe the customer will hacksaw the appliance open to get your code, consider encrypting the storage medium.... Then they have to hacksaw the box AND find the keys. A TPM chip or secure USB token may aid with the latter.
Being a shareware author and longtime member of ASP myself i think you are going into the wrong direction with your solution. The only way to make this workable is with a hardware device as already suggested. This or constant online activations is the only way if you want to be sure and your product is so good and without competitors that your customers will still use it.
But what we (organized small ISV's) learned from practice is that you should not do what you are trying to do. Do not bind it to hardware. Sell one license per person not one license per computer. In the end you will make more sales because of the relaxed license.
Just do enough to make the honest people stay honest. So limit the trail version (i decided to terminate the application after one hour for me) and leave the final version free from all stuff. Give a separate download for payed customers and thats it. Be a nice company and not a greedy profit maximizing by legal restrictions company.
I used some of the better windows protection programs first but they all had serious problems with my code. And they call get cracked sooner or later. So i gave up all of them.
P.S.: I use a hardware fingerprint schema on windows where i don't restrict the program but just to keep people away from getting new trial keys every 30 days. Together with a nag screen it seems to work. The fingerprint is an xor of user name, windows installation time, modify time stamp of a system files and harddisk serial id.
Let the registration code also be the activation code.
You generate the unique registration code at point of sale, or packaged with the product. Customer registers/activates/deactivates with you (or your server) in one step using that single code. The customer's hardware doesn't have to generate any keys.
Reregistering/reactivating still requires contact with you, so you're aware of reinstall attempts.
I think that the only solution to your problem is a cryptographic hardware dongle. Usually it would be a USB-based tamper-resistant challenge-response dongle, that can be easily transferred between computers.
These devices cost less than $1 for large quantities, and not more than $10 for very small quantities. The good ones are very hard to forge, very easy to embed in your application, and usually supplied with a free EXE encryptor which also contains anti-debugging and anti-reverse-engineering functionality.
A customer wants their product to require users to enter a machine-specific code, so that they can only run it on one machine... if they want to use it elsewhere they get a deactivation code from the first machine and send that back to prove this.
If the app could talk to their server this could be made much smoother but this is not the case. I thought of a workflow but it's a bit convoluted:
Customer purchases a license and is emailed a serial code
Customer installs App and is prompted for serial code
App generates a machine-specific code and performs some operation combining this with the serial code, providing this PC-Code to the Customer
App now requests an Activation code, once entered it will run
Customer sends PC-Code to Vendor who check it's valid against their recorded serial code, and using both generates an Activation code which they send to the Customer
The idea is PC-Code and Activation Code are both short, more like pin-numbers, so it's not too horrific... but is there a better system? And how can specific steps be implemented?
I personally don't like restricting the customer so much but it's not my call, it's been argued to death already :)
By using an activation code step you are effectively forcing the customer to be your internet connection. Unfortunately without this step you can't tie them down to a machine.
The biggest problem is going to be your deactivation code - if the customer writes down their activation code what's to stop them using it to reactivate their PC again?
The only way would be to have your activation code somewhat based on date so that they get a week or month to enter it. They'll probably never notice an issue unless they need to a reinstall in which case you can reissue another activation code (provided there isn't an outstanding non-deactivated code for a different machine).
How programming-competent are your customers and how motivated will they be to crack your software?
This article provides some good ways on getting hardware information.
This is why hardware keys are used, you cannot physically plug it into two devices at once. The only method with software requires a trusted third party to manage quorum, i.e. authentication servers over the Internet.
One popular unique identifier for Unix licensing is the hostid. A modern alternative would be to include a secure token generator such as the RSA SecurID. Have the administrator read the token over the phone to the vendor, pass through some algorithm to generate a key to unlock the software.
Everything else is going to be smoke and mirrors.
We would like to run a wireless access point for public use. However, in case of misbehavior, we would like some personal information to be able to pass on to law enforcement.
The proposed solution involves a captive portal where users enter their email addresses, and are then given ten minutes to check their email and verify, after which they are given unrestricted access.
The problem, as I see it, is that once a user is authenticated, anyone can come along, spoof the MAC or IP, and then have access. If they commit a crime or copyright infringement, the user who entered the email address is now blamed.
Now, we could solve that by using WPA and requiring users to preregister. But as I said, we would like to allow anyone to just drive up and use it, and we don't want to provide any technical support.
The other alternative is not collecting email addresses, but then in case of an investigation or lawsuit, we wouldn't have anything to hand over, and thus risk the possibility of being shut down.
Is there any way out of this dilemma?
Collecting email would also be futile since you have no good way of confirming it without also providing compromised access. You should simply log the traffic that the user generates.
The answer is to not care about unsatisfiable demands from law enforcement for the personal information of your users. If that's not an acceptable answer, then the answer is to stop trying to provide a public access point. If that's not an acceptable answer either, then the answer is the proposed solution you already have. How you go about living with yourself afterward, for collecting personal information from law abiding people that will only ever be used by criminals to cover their tracks, is a personal matter and out of scope for this site. Good luck.
Having the end-user accept a legal disclaimer that you (the provider) are not responsible and they (the end-user) is responsible, and that they should not do illegal things is usually good enough. Just log that they clicked "I agree" and their IP and MAC at the time. They should have to do this every time they connect.
Asking for an email is basically worthless; many will use a made-up email, or enter a typo, then complain they never got it - many will use a disposable email - many will use a junk account they create with one of the free webmail providers.
A system that sends their mobile phone a TXT message with a unique (random) code, and having that entered on the captive portal page to gain access is a better system IMHO. I've done this before and it works OK, except for kids who have mommy's iPad or another tablet but no phone. You save all this data for 90+ days, or however long your lawyers tell you.
Realize that implementing any of this significantly decreases the actual use of your hotspot, users don't have the patience and will be frustrated and abandon the process.
Most captive portal products can log the MAC and IP lease every client gets, and where they go on the Internet (at least that's how I do it) so if a legal request comes along, you can give law enforcement the data you have. It's up to law enforcement to then steak out or track down the device with that MAC, which depending on their competency level is possible, or impossible for them, either way it's not your job to do their job for them.
I also advocate filtering the obvious porn and malware domains, not just to save on bandwidth, but to limit your liability. Any good captive portal product can do this.
Your public wireless network should at the least be NAT'd to a separate static IP, so you can differentiate legal requests that reference that IP, as opposed to say your private office network. You can do this with separate firewalls, or a firewall that supports multiple LAN interfaces.