11-16-2009 08:25 AM
My company has a great app for BlackBerry that has attracted enterprise customers. They want to push the app out to all their BlackBerry users. Normally the app needs an activation code to prevent it from being pirated but for this scenario we need to provide a full-featured, no-activation build so all the users at the company don't each need to bother with activating.
However this opens the door to the BES administrator leaking the cod and alx files for the full-featured app to people outside the organization, or the general public. Not a huge concern with legitimate businesses, but one I'd like to address if possible.
So Is there a way to somehow create a special build of the app that only works on a particular BES instance, or for a particular organization?
My only idea, which seems like a big hack, is the write code inside the app to get the primary outgoing email address configured for the BlackBerry and make sure the domain name is xyzcompany.com.
I'm thinking there must be a standardized way to do this....
Thanks!
11-16-2009 08:41 AM
you can put a license key into the it-policy, as a first step.
you could generate this license key with a special e-mail domain, like company.com, or a list of domains, if the customer has multiple. in your application you can check the activated mail address for its domain and allow the app to start only if the domain encoded in the license key matches the retrieved one.
11-16-2009 12:39 PM
You could generate a license key that is bound to a particular named BES.
For example:
1. Generate a public-private key pair and keep the private key really private inside your organization (i.e., don't distribute it!).
2. Embed the public key into your application.
3. Sign the name of the BES with the private key, and let the BES admin deploy this signature to devices (e.g., via custom BES IT Policy entries/settings).
4. Your app will obtain the name of the BES (from the Service Book records) and verify the signature using the public key it has.
Issues:
1. Use something better than the name of the BES. E.g., the UID of the Desktop [IPPP] SB record might be better, since (I believe) it's unique across all BESes and much harder to spoof.
2. An evil customer could replace the public key inside your application with their own (for which they have a private key).
11-17-2009 12:10 PM - last edited on 11-17-2009 12:12 PM
Simon and klyubin-
Thanks for the feedback! At top level this email idea basically sounds like my original idea, and hearing it from others makes it sound more plausible and less "hack"-y.
So how would one put a license key into the IT policy so that it is accessible from the app?
And how can the app get the BES name from the service book records?
And can someone cofirm that the UID of the IPPP record is unique to a BES instance?
I think we're on the right track here... good stuff!
Nicholas
11-18-2009 05:05 AM
custom it policies can be created on the bes, ask your bes admin about it. on the device you can read them very easily using the ITPolicy class.
11-19-2009 01:25 PM
Thanks for all the help on this. Looks like this is the way to go. For anyone who stumbles across this thread in the future, here's my code:
To get a user-defined string from the IT Policy:
String licenseCode = ITPolicy.getString("MyAppLicenseCode");
To get the UID of the IPPP Service Book entry:
for (int cnt = srs.length - 1; cnt >= 0; --cnt)
{
// identify the service record associated with a mail message service via a CID of 'CMIME'
if (srs[cnt].getCid().equals("IPPP"))
{
ServiceConfiguration sc = new ServiceConfiguration(srs[cnt]);
String UID = sc.getUID();
// do something here to check against the license code
}
}
If anyone sees any flaws in this system I'd love to hear about them! ![]()