02-11-2010 04:47 AM
Solved! Go to Solution.
02-11-2010 09:01 AM - edited 02-11-2010 09:07 AM
I'm not aware of an official document describing how signing works.
I believe it works as follows. Take this with a grain of salt though.
There is a separate signing server for each signer ID (e.g., RRT, RBB, RCC). Each RIM signing server has an RSA public key pair. The public key is hard-coded in BlackBerry firmware (e.g., RRT, RBB, RCC public keys) so that it can verify module signatures issued by RIM. The private key is used for generating code module signatures (the SHA-1 hash of the module's contents is signed by the key). In order to restrict access and to link signatures to customers, RIM signing servers receive a customer ID in each signing request. They then check whether the customer who is requesting a signature is actually authorized to receive it. For each code signing key (e.g., RRT, RBB, RCC), there is a database containing, for each customer, the customer ID and the DSA public key associated with the customer.
The Signature Tool identifies itself to RIM signing servers using a customer ID and a DSA public key pair. The private key is stored in the password-protected sigtool.csk file. The public key is not stored anywhere as it can be easily derived from the private key. With each code signing request the Signature Tool, based on the signer ID of the signature requested (e.g., RRT, RCC), looks up the URL of the signer and customer ID from the sigtool.db. The Signature Tool then sends the SHA-1 hash of the module, a DSA signature of the hash, and the customer ID to the server. The DSA signature and the customer ID are checked by the RIM signing server to verify that request comes from an authorized customer. If everything goes well, the server's response contains an RSA signature of the hash. The Signature Tool then adds the signature to the module.
In order to populate the customer database (with the customer's DSA public key) and the customer's sigtool.db (with the customer ID, signer ID and URL for each signer) RIM generates a registration public key pair for each signer for each customer. The registration public key is stored in the customer's record (not to be confused with the DSA public key used during signing) in the customer database, and the registration private key, customer ID, and signer URL are wrapped into a .CSI file and sent to the customer. The customer's Signature Tool, upon opening the .CSI file, sends the customer ID and its DSA public key signed/protected by the registration public key to RIM, and, if the operation succeeds, adds the corresponding customer ID + signer ID + signer URL record to sigtool.db. As a result, RIM signing servers know what DSA public corresponds to which customer, and customers' Signature Tools know where to connect and what customer ID to send in order to request signatures.
Note that if the Signature Tool doesn't yet have a DSA key pair, it generates it and saves the private key in sigtool.db.
P.S. You can also install and run your own signing server (aka websigner) which is freely available from RIM. The only difference will be that the RSA public key associated with such a signing server is not hard-coded into BlackBerry firmware and thus the BlackBerry OS cannot verify the authenticity of the signatures unless your software provides the OS with the public key.
02-11-2010 03:42 PM
Thank you very much. I will digest it bit by bit. Some follow up questions. If I make a change to the modules (I got 3) does that mean I have to go thru the process again? Or part of it?
02-11-2010 03:55 PM
This depends on what you mean with "the process".
A code module signature is based on the hash of the module's contents (minus the trailer that contains the signatures). If a module changes, the hash most likely changes too, meaning you need to get new signatures for the module. Even if you don't change the code or resources contained in the module, simply rebuilding the module updates the timestamp stored in the module. As a result, the module's contents change and it needs signing.
For every module and signature you need to obtain, the Signature Tool will send an HTTP request to a web signer server. For example, if you need to have three modules signed with the usual four RIM keys (RRT, RBB, RCR, RCC), the Signature Tool will make 12 signing requests.
Then again if you don't care about all this nitty gritty, all you see is that you start the Signature Tool telling it to sign the three modules and the Signature Tool does it for you displaying the progress while doing so.
02-19-2010 04:58 PM - edited 02-19-2010 05:00 PM
This is such great info to know, thank you so much!
I do have a question regarding protecting runtime store and persistent data a code signing key. This sample code was given in the demo application:
PersistentObject controlledStore = PersistentStore.getPersistentObject(PERSISTENT_STO
CodeSigningKey codeSigningKey = CodeSigningKey.get( CodeModuleManager.getModuleHandle( "PersistentStoreDemo" ), "ACME" );
controlledStore.setContents( new ControlledAccess(new Vector(), codeSigningKey));
The comments mention that the "ACME" key needs to be generated using BlackBerry Signing Authority Admin Tool, the code needs to be signed with this tool using this "ACME" key in order to be granted access to the protected data. This tool to me seems like a legacy tool, as it's latest version is from 2005. My question is whether we still need this method. If yes, does that mean, we need to sign twice, once using the rim servers for controlled api access, and then again signing with the self generated "ACME" key?
Also, even if it has to be signed twice, can we use the public/private key pair that was generated when installing rim signatures? Is there a way to extract this particular public key to ship it with the application as this is required?
Sorry for so many questions. I haven't been able to find answers through the documention and forums. You're the most knowledgeable regarding this I've encountered.
02-22-2010 07:35 AM
You have two main options:
1. Get RIM signatures using the Signature Tool, and then manually load the signed modules into the File Signer (part of the Password Based Signing Authority suite) and sign them with the ACME key.
2. Get RIM and ACME signatures in one go using the Signature Tool. In this case you need to add a customer/record/client (yourself) using the Remote Client Administrator tool (part of the suite), which will then send a .CSI file to the e-mail you specify (yours), then open that .CSI file in your Signature Tool to register your Signature Tool with the ACME signer. You need to ensure that the "BlackBerry Signing Authority ID: ACME" Windows Service is running and is reachable from the PC where you're running the Signature Tool.
02-22-2010 10:10 AM
Thanks a lot.
Just one more question, this "ACME" key is just an self generated example key, right? I would need to generate my own key using the Password Based Signing Authority Suite?
02-22-2010 10:42 AM - edited 02-22-2010 10:42 AM
Correct, the tool will generate a new key pair. Also, it doesn't have to be named "ACME" -- you can use an arbitrary 4-character signer ID of your choice.