Windows Mobile 5.0 Security Model FAQ


Certificates (SSL)

Q: What is required to install a new certificate to the ROOT store?
A: Adding ROOT certificates currently requires trusted code or manager access. On most Pocket PC devices this won’t be a problem, but some Smartphone devices are deployed in a restricted configuration where this will be a problem.

Q: Okay, I have a restricted Smartphone device. What are my options for getting a root certificate on there?
A: In the general case, you will need a signed certificate installer. Some operators provide this tool. There’s a more in-depth discussion of this issue at the blog post here.

Q: Does Windows Mobile support wildcard certificates?
A: Not in the current versions.

Q: Does the certchk tool work for disabling SSL validation for Exchange ActiveSync?
A: Not on Windows Mobile 5.0 devices. There is currently no workaround for this beyond adding the root certificate as described above, or disabling SSL altogether.

Application Security and Code Signing

Q: Why doesn’t the device trust my code? I bought a code signing certificate from a CA!
A: Because the certificate doesn’t chain to an execution root on the device. For a binary to be trusted, the cert must chain to a certificate in the Privileged or Unprivileged Execution Authorities stores. A typical Windows codesigning certificate from a CA won’t work. Get a Mobile2Market certificate to run on the widest variety of devices.

Q: But why does it say “Unrecognized Publisher”? My code signing certificate was purchased from Verisign!
A: Since we can’t verify the certificate chain, we cannot trust the certificate at all. We don’t show any text from the certificate to reduce the spoofing risk to the user.

Q: Do I have to sign resource-only DLLs?
A: Yes. This is a change in Windows Mobile 5.

Q: Why do you need a privileged certificate to load a driver on PPC? Everything else runs trusted with an unprivileged certificate
A: During boot time, the device has not finished initializing and processing configuration XML. Only the privileged execution store is trusted until the boot is finished. If you can wait to load until after boot finishes, things will work as you expect. See the post “Getting your unprivileged drivers and services to work” for a more in-depth description.

Q: What is the point of code signing? It doesn’t ensure that the code is well written, or that it is not malicious.
A: Code signing provides a reliable means of verifying the identity of the developer of the code. It also provides an integrity check to ensure that binaries are not tampered with, and a path for revocation of malicious or badly flawed applications.

Q: How do I know which APIs require trust and which don’t?
A: Start here

Q: How do I sign my code for day-to-day development?

A: In general, install the SDK certificates and then sign your code with them, or configure Visual Studio to do so automatically. The emulators have the SDK certs installed already, so you can skip that step for those. More detailed step-by-step instructions in the white paper under “Signing an Application During Day-to-Day Development.”

Mobile2Market


Q: Do you have to sign the cabs and the files inside the cab?
A: Yes. We realize this can be less than ideal, and expensive for an ISV to get that many signing events. It’s on our radar for things to improve.

Q: Why should we have to go through the Mobile2Market program at all? Why can’t I run whatever I want on the device?
A: Most Windows Mobile 5.0 devices are deployed on private networks owned by the mobile operators. To protect these networks from malicious software and limit support costs, many operators have stringent requirements limiting which applications can install and execute on connected devices.


Q: Isn’t this just a scheme to make application developers pay Microsoft every time they want to ship an app?
A:  No.  The cost of signing your code with a Mobile2Market cert goes directly and entirely to the Certificate Authority, either Verisign or Geotrust.  Microsoft does not participate in this commerce in any way.  Microsoftโ€™s interest is strictly to provide the most unified application security model possible so that a single signing process will allow you to deploy your application on the greatest possible number of Windows Mobile Devices.

Q: Will my Mobile2Market application run on all Windows Mobile 5.0 devices?
A: As of today (12/18/2005) Mobile2Market certificates are currently included on all new Windows Mobile devices sold worldwide with the exception of those sold by two mobile operators; Orange and SKT (South Korea).  Orange devices currently ship with the Mobile2Market certificate only in the unpriv store, and with an Orange certificate in the priv store.  SKT devices ship without any Mobile2Market certificates.  This means that when your unprivileged application is properly signed with a Mobile2Market certificate it will run on every device worldwide, except those sold by SKT.  Your privileged-mode application will run on all devices worldwide except those sold by Orange or SKT.

Q: What about previous releases of Windows Mobile?

A: Code signed through the Verisign program should run on devices dating back to the 2002 release. The Geotrust root is on devices starting at 2003SE. We’re investigating a solution to allow end users to install the Geotrust root on devices so they can run these programs.
 

 

edit 12/28/05: broke into two sections, typos, added two new questions. Disabling comments for this post to reduce clutter – you can mail me directly to add new questions or comment.

edit 1/4/06: Comments back on after customer feedback. Comment to your heart’s content. The offer to mail me is still open – you’ll get a faster response that way.

edit 1/5/06: Added certificates section.

edit 4/12/06: linked to “what requires trust?” blog entry

edit 12/8/06: day-to-day development signing 

edit 3/15/07: added note about Geotrust cert and downlevel devices 

Comments (121)

  1. Shane Church says:

    "Q: Isn’t this just a scheme to make application developers pay Microsoft every time they want to ship an app?

    A: No. The cost of signing your code with a Mobile2Market cert goes directly and entirely to the Certificate Authority, either Verisign or Geotrust. Microsoft does not participate in this commerce in any way. Microsoftโ€™s interest is strictly to provide the most unified application security model possible so that a single signing process will allow you to deploy your application on the greatest possible number of Windows Mobile Devices."

    Maybe this doesn’t make Microsoft any money but it makes life close to impossible for the hobbyist developer. $431/year for the cheapest certificate from Verisign, and a minimum of $200 per logo certification test makes for a very expensive application. The code signing and testing requirements will raise the cost of applications to all end users and will severely limit the amount of vendors of any sort willing to write software for the Windows Mobile platform. I have been writing Pocket PC applications since Pocket PC 2000 as a hobbyist and this is the type of requirement that seems designed to drive all but the large corporate developers out of the Windows Mobile market.

  2. Vincent says:

    This signing process is just plain bad. It’s a bureaucratic, costly process, based on nothing but unjust and exaggerated fears of network pollution by the operators. We market a professional solution to produce video ringtones for Smartphone. The software allows publishers to turn their catalogue of video content into video ringtones. The videoringtone is a cab file that contains a wmv-video and an executable. Because both the .exe and the .cab have to be signed, it means that our customers will have to sign every video ringtone they produce. And most of them will be producing many hundreds. They have to go through this incredibly bureaucratic process, let alone the costs involved. If only the .exe would have to be signed, this wouldn’t be an issue. Very bad business tactics, Microsoft.

  3. scyost says:

    Hi Vincent,

    From the situation you describe, I don’t understand why your customers would need to resign their cabs. If you’d like to mail me directly (click through to my profile to mail me) , I’d like to hear more about the setup.

  4. Yuhong Bao says:

    Looks like you won’t have to sign the cab if wceload.exe isn’t used to install it. Although if it is used to install the cab file you will need to sign it.

  5. David Koch says:

    What are the easiest method to sign with the ‘Mobile2Market unpliviledge certificate’ some DLL/EXE/CAB, and what does it cost ? Things are getting confusing across all blog/forum/faq I read up to now. What I understood is there is a 4 steps process to get this done :

    1- Sign-up to http://www.mobile2market.net/ (what requirement ? Hotmail/Passport account ? …)

    2- Get a customer certificate here for instance (pay xxx $) : http://www.geotrust.com/codesigning/smartphone/order.htm

    3- Sign each DLL/EXE/CAB with the customer certificate

    4- Re-sign each DLL/EXE/CAB with an ‘event’ certificat here (pay another xxx $) : http://www.geotrust.com/products/signing_services/code_signing.asp

    What is the cost per CAB (which contains several DLL/EXE files) ?

    Discuss all turns around SSL and Microsoft Exchange. Is there a need of such things to sign Windows Mobile 5 binaries ?

    Kochise

  6. Veri Sign says:

    Code signing service offered by Verisign really sucks. They are only interested about the $ they get from each file we sign.

    First there was a problem that downloading signed files from Verisign web site did not work at all from a PC with Windows XP Service Pack 2 installed. They just told us to "use a PC with XP Service Pack 1".. Now half a year later it finally seems to work also with SP2.

    The most annoying problem is that you have to sign all DLLs, EXEs and CABs separately one by one. With e.g. 10 of supported languages (we will soon to have even more) in your application you will soon have tens of DLLs and EXEs to sign. Currently it takes one work day from us to sign all the files, create the cabs etc. In addition being very expensive this manual work is also very error prone.

    I am sure they could use the cabsigner tool from Microsoft. Using it all the signings could be done in a single step. Maybe they want it to look as difficult as possible to have a better reason to get our money for nothing.

  7. Gili says:

    The i-mate sp5 might have a signed certificate installer but this does not work for the sp5m. Any ideas how to make this work on sp5m?

    Thanks,

    Gili

  8. Nargis Ali says:

    Trusted Certificate on Treo 700W

    We downlaoded the sign tool .exe from microsoft and ran it to sign the cab file and it signed successfully. However there were still problems. Our certificate is with VeriSign and they have been trying to help us to.

    When we dropped the cab file on the pocket 2003, that does not require any certificate, we got an error message "this cab file is not valid".

    When we dropped the cab file on the Treo 700w, we were able to successfully drop it but it still said "this program is from unknown publisher".

    Any idea?

  9. scyost says:

    Gili: that would be a question for iMate.

    Narqis: PPC2003 can’t install signed cabs. That’s the reason for the first error. For the second one, did you sign with a Mobile2Market certificate from VeriSign? If not, it won’t work. (described more in the first two questions under Code Signing above)

  10. Jamie Le says:

    I went throught the whole process of purchasing the cert from Geotrust. Got all the binaries signed and resigned.  packaged them in a cab.  Got the cab signed and resigned.  Load the cab up on the device and still got the "unknown publisher" error.  Does anyone knows why this is happenening?

  11. scyost says:

    Jamie:

    Make sure every binary executable in the cab is signed. That means every DLL, EXE, CPL – anything that gets executed.

  12. bob mahavowitz says:

    all I know is my friggin pacman that I purchased won’t install on Window mobile 5. WTF?

    someone call namco and get them to re-release the file with all the "signing" hoops jumped thru.

  13. David Koch says:

    I need to use ‘CeRapiInvoke’ from the PC side to access a helper DLL on the PocketPC, which will returns the Pocket PC ID or free space on media…

    Currently, on PDA phones, the ‘CeRapiInvoke’ calls fails with the E_ACCESSDENIED error code. By ‘unlocking’ the PDA phone, I can get the ‘CeRapiInvoke’ call to succeed. But I cannot expect all users to ‘unlock’ their PDA phones.

    So the question remain : what should I get signed/certified (DLL/EXE/CAB ?), under which level of digital signature/certification (M2M/Verisign/Orange ?) and for what x-tier protection level (one/two tier ?) ?

    I spent hours reading ‘how-tos’ and forums, and things are still quite fuzzy to me. Our applications don’t access ‘sensible’ data or VPN, we just needs to get access to our helper DLL, install(CAB) and execute(EXE) our softwares ๐Ÿ™‚

    In facts, get the WM5 plateform to behave like the good ol’ days where the ‘signing theory’ was just under plan…

    So the questions are : What’s necessary, what’s for and for which plateform…

    Kochise

  14. scyost says:

    Check out the ’05 MSDN docs for CeRapiInvoke – they explain how you need to add an entry to the metabase for the DLL you want to invoke. The only other issue is that DLLs for CeRapiInvoke must be signed privileged (because they are loaded into the sync process). So, to distribute that on the widest variety of devices you’ll need a privileged M2M certificate.

  15. David Koch says:

    OK, I’ll try a "privileged M2M certificate" for my DLL. What should I do first, open an account at M2M or one at GeoTrust (for instance) ?

    Then for my EXE/CAB, should I use the same "privileged M2M certificate" I use for the DLL ?

    And thanks for having answered ๐Ÿ™‚ That helps…

    Kochise

  16. Frank says:

    Privileged or Unprivileged? How can I tell which type of certificate a dll/exe needs to be signed with?

    Is there a check list somewhere that would allow me to determine this?

    I saw a list for Pocket PC 2003, but not Windows Mobile 5.

    Which type of certificate is needed for an ActiveSync sync service provider dll?

    Thanks,

    Frank

  17. John says:

    I just cannot understand why this thing is so complex.  I have a PDA running WM5, I installed on it an "AddTrust External CA Root" certificate which our company uses, and I cannot sync with Exchange (error code 80072f17).  My IT guy is at a loss, and so am I.

  18. David KOCH says:

    Well, an internal discuss is running here, on how the GeoTrust Smartphone Credential would help us. We are talking about WM5 PocketPC and PDA phones, and some people here are ‘blaming’ me for registering ‘Smartphone’ credential, which seems to be useless for our concerns (PDA phones, Orange SPV units, not Smartphone without stylus)…

    Everything turns around Smartphones here, but can the PDA phones policy be compared to Smartphones ? Are the ‘Smartphone credential’ compatible and useful to run DLL on PDA phones ? Or have I made the ‘mistake’ to register Smartphones credentials ?

    Could a clear and obvious distinction be made between PDA phones and Smartphones, from a policy and software point of view ? What is comparable, what is not ?

    Kochise

  19. Thom says:

    Why is it that all my dll wont install and my remove programs list is empty though the app still lanch?

  20. Exchange Server 2003 SP2 – Windows Mobile 2005———————————————-

    Microsoft…

  21. shch says:

    Guys, I’m do not have access to a PPC or a Smartphone, but is there a way to sign an application in such a way that it will not be run if it was tampered? Line in the Symbian OS? Thank you in advance!

  22. scyost says:

    For an unsigned app, no. For a signed app, if the signature is actually invalid because the app was tampered with, the application will not run at all. This is true regardless of what certificate was used to sign the app.

  23. Kochise says:

    I done everything scyost asked me to do :

    1- Request a M2M privileged signing account (just got it)

    2- Sign the DLL with this privileged account

    3- Set the system attribute to my DLL

    4- Provide CabWiz a /postxml XML provision file

    5- Compress everything in a CAB with the provision file

    6- Sign the CAB with the privileged account

    7- Still no luck, can get the DLL to work, always getting a E_ACCESSDENIED in the face…

    Have I missed a step ?

    Kochise

  24. scyost says:

    Did you add the DLL to the metabase as described in the CeRapiInNvoke MSDN docs? I’m not sure if that was part of your step #4 or not.

  25. Kochise says:

    Provision file content :

    – – – 8< – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

    <wap-provisioningdoc>

      <characteristic type="Metabase">

         <characteristic type="RAPIWindowsCeGetInfos.dll*">

         <parm name="rw-access" value="3"/>

         <parm name="access-role" value="152"/> <!– 152 maps to "CARRIER_TPS | USER_AUTH | MANAGER" –>

         </characteristic>

      </characteristic>

    </wap-provisioningdoc>

    – – – 8< – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

    Ths CeGetInfos.dll is installed in the Windows folder, with the system and archive attributes…

    Kochise

  26. LuisCa says:

    Kochise,

    What does your CeRapiInvoke call looks like? Did you give it the full path to your DLL on the device?

    Thanks,

    -Luis.

  27. Kochise says:

    What I done till today and works on non PDA phone edition (so that’s why I permited myself to think it’s not a path issue) :

    – – – 8< – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

    l_nResult = CeRapiInvoke

    ( _towchar("CeGetInfos")

    , _towchar("CegiGetStoreInformation")

    , l_nLenInput

    , NULL

    , &l_nLenOutput

    , (BYTE**) &l_psStoreInfo

    , NULL

    , NULL

    );

    – – – 8< – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

    Kochise

  28. Alex Jones says:

    Wow, I just started some serious WM 5.0 development, and I must agree with most, this whole certification stuff is a huge amount of BS and cost to us small developer shops that it’s just very discouraging and disgusting.

    The whole untrusted code on mobile devices issue has been wildly exaggerated by Verisign/Geotrust and the carriers + MS swallowed it hook, line, and sinker.  Disgusting.

  29. Stuart Hall says:

    I can’t emphasise enough, just how bad the current code-signing mechanisms are in WM5 / Smartphone:

    1) The process to get code signed is truly awful – MS are, I believe, being held to ransom by Verisign and Geotrust.

    2) Signed CAB files don’t work on platforms that don’t expect them (basically, everything but SP and WM5) <- How bad is this? Well it means that our unified product distribution process, suddenly needs different versions for different software releases on the same platform, even though the underlying software remains the same.

    3) The process is expensive

    4) Mobile operators have the ability to undermine the whole system anyway by refusing to carry the MS root certs (*cough* Orange *cough*)

    5) If you have lots of files or languages to support, you’d better get yourself an intern to sit and sign the files, ‘cos it takes *ages*

    6) Yey for signing both the app and the container. I can’t see any reasons why that would be bad. Oh, hang on. You mean that it will take even longer and cost even more? Nooooo, surely not.

    7) And then, when all is said and done, I can still write an app-trashing virus, sign it and deploy it to the world without the smallest hiccup. Revoke the app cert, I hear you cry? Because the whole deployment method for WM is so bulky, it takes at least 6 months for any ROM updates to get from Microsoft to end users, assuming that they update promptly. And many updates never get sent out at all. *sigh*

    Sorry Microsoft. I don’t know what you were thinking of when you designed this process, but all you’ve managed to do is annoy your OEMs, piss off your developers and make a shed load of cash for Verigeosigntrust.

  30. Laurent Chazareix says:

    All this is really confusing and I found no place with consistent information. I want to have my code signed for Pocket PC running WM5.0. I understand that it is necessary to sign it with a mobile2market certificate (not sure) but there is no information on the m2m site about this (who is able to sign with mobile2market certificate), only marketing. I enrolled for ACS publisher with Verisign but I now understand that this is for Smartphone only, I asked to Verising but they could not give me any useful information or any link with mobile2market program. Please help.

    Laurent

  31. daern says:

    Laurent: It’s the same signing program for Smartphone as for WM5. The root CAs are the same for both, so you can sign apps for WM5 in exactly the same way as for SP.

    Hope this helps,

  32. scyost says:

    Hi Stuart:

    2) It’s true that signed cabs don’t work on PPC 2003 and AS 3.8. However, they do work for all smartphone devices, all Windows Mobile 5+ devices, and all devices when installed through ActiveSync 4+.

    Given that PPC 2003 as shipped cannot parse signed cabs, what sort of solution would you be interested in seeing for that?

    4) We can’t force Orange to put the M2M certs in. It’s their phones, their network, and their choice. It’s also only the privileged M2M certs that they don’t have. They have their own signing program for privileged apps. The M2M unpriv certs ship widely.

    7) If an application needs to be revoked to protect customers, the revocation can be deployed over-the-air. You don’t have to have a  ROM update.

  33. daern says:

    Thanks for the feedback Scott. Sorry it sounded like a rant (which it was) but I was having a really bad day with this yesterday.

    Some feedback:

    2) I suppose the solution I would have liked to have seen would have been support for signed CABs from day one. At the very least PPC2003SE should have been able to at least parse them, even if it was unable to do anything with the certificates. SP has supported signed code and CABs since before PPC2003 was released, so it was quite an oversight to leave this out in PPC2003…

    4) Point taken, but you are the licenser and could, perhaps, have forced the issue with Orange. I can, however, see that this is not a technical, but rather a commercial issue with a major (read first) SP OEM and that they might have had more influence than later OEMs.

    7) Point taken. Who controls the CRLs for PPC? Microsoft? OEM (e.g. HTC)? Network? Geotrust & Verisign?

    One question, if you don’t mind indulging a ranty developer for a moment… I have a CAB signed against Geotrust’s unpriv CA, which contains (amongst other things) a couple of DLLs (both signed unpriv) and a setup DLL (again signed unpriv). When I load this CAB onto my device (WM5, HTC Wizard) it still moans about it being unsigned. I’ve checked and double checked and I’m sure it’s signed correctly. I’ve dumped the certificate store from the device using rapiconfig.exe and confirmed that, not only is geotrust’s root un priv cert installed, but that the thumbprint matches the root cert in the chain for the signed file.

    Can you suggest where else I might look? Code and CABs signed with the Priv. CA work just fine on the same device.

    (Device is a UK O2 XDA Mini-S, running an AKU2 ROM)

    Thanks for indulging my rant ๐Ÿ™‚

    Stuart (daern)

  34. scyost says:

    2) I can’t fix this right now but I can at least offer some technical context. I’ll add it in a bit.

    4) It’s true that we could try to change their minds from a business perspective, but this is something that’s very important to them. We certainly would prefer everyone ship the M2M certs.

    7) The CRLs aren’t really exactly the same as traditional CRLs. It’s a list of hashes and the hashes can correspond to code execution certificates or binaries themselves. It’s not used for revoking SSL certs or anything like that. We (MS) can ship some in the default image, the OEMs can add some if they want, and the operators can add some if they want. Additionally they can be added at runtime or over the air. It’s just xml via the LoaderRevocation CSP. (doc’d in MSDN)

    For your code signing question, have you verified that the cert you signed with is in the SPC store? (it certainly should be but that could explain the symptoms you are seeing)

    Can you load the DLLs by themselves?

  35. daern says:

    Hi Scott,

    Yes, the cert is in the store. I’ve dumped the store with RAPIConfig.exe and checked that the thumprint of the appropriate cert in the store matches that of the root cert in the chain of the signed file.

    Because the DLL is a CAB file extender, it’s a pain to load it standalone, but I may have to do that if I can’t sort this out.

    I’ve now discovered another CAB that is signed ok but still moans about being unsigned. This is just getting weird… I’ve got a case open with Geotrust so perhaps they’ll be able to help.

  36. daern says:

    I’ve discovered that there is one .exe in the CAB that is not signed *but* it’s not actually executed at runtime (it’s a utility). Will a CAB file report as "unsigned" if *any* of the binary files contained within it are unsigned?

  37. scyost says:

    Yes, if any of the binaries in the cab are unsigned, then we will put up the prompt at install time. Once the prompt is accepted, we add the unsigned binaries in the cab to the prompt exclusion list, so that when the user goes to run them they don’t prompt.

  38. daern says:

    Thanks. That helps. How does it decide which files are binaries and which are not? File extension? Are there any other file types bu EXE, DLL and CPF?

    We have some DLLs that are renamed to .MPD files (for some weird legacy reason!). Would it detect these?

    And one last question…do all files in a package have to be signed to the same root CA as the CAB file? Can I deploy 5 binaries as non-priv and one signed priv in a non-priv CAB file?

    Thanks,

    Daern

  39. scyost says:

    It examines the file to see if it "looks" like an executable. (has a PE header) So it will see your MPD files. I don’t think it will count a CPF file – those are just CAB files and they’re not considered executables in this case.

    The files don’t have to chain to the same root cert – they all go through the security loader individually. The real criteria is "Will this binary prompt upon execution?"

  40. daern says:

    Cool. Thanks Scott. I’ve put aside some time to look at this today, but I’ve checked and both of my problematic CAB files contain a single, unsigned PE file so I’m optimistic of a solution…

    Is this stuff documented anywhere in MSDN?

  41. daern says:

    I can confirm that this has fixed my problem with these two CABs. Thanks very much.

  42. Bill says:

    I have a CAB file that I can successfully install on my Axim x51v.  It also has been installed on several users’ devices without issue.  However I have two users who have the Dell Axim x51v and they receive the "unknown publisher" prompt and then the installation fails.  I’ve discussed this with GeoTrust and they are as perplexed as I am.  Any ideas as to what could be happening in this situation?

  43. Mike Edgar says:

    Hello,

    We received a privleged certificate from GeoTrust (installed it on to the USB drive, etc.), signed a test.exe file, installed that test.exe on the mobile device by copying it over via Active Sync, and it failed to run with an error code of 50 and error of "The request is not supported."  

    This is the same error we get when we don’t have the application signed with a privieged certiicate.  

    We think that we need a M2M Root certificate  installed in the Windows Mobile 5.0 device’s root cert store … but we don’t see any M2M or Microsoft Root cert there.  Is it supposed to be visible?

    I’m following up with GeoTrust and M2M, but if anyone has some helpful info/ideas that’d be great.

    Thanks!

    – Mike

  44. daern says:

    Hi Mike,

    First things first. When you say that you have signed the file, have you signed it using the certificate on the hard key *and* submitted it to Geotrust’s web portal for signing against the M2M root CA? If you’ve only done the first bit (using signcode.exe) then your app isn’t actually signed. Well, it is, but not against any root certificate on the device ๐Ÿ˜‰

    Next: What device are you using? I believe that virtually all devices have the standard M2M root certificate installed, and that most also have the priv. certificate. Have you tried dumping the app certificates from the device using RAPIConfig.exe – very informative and this will tell you whether or not you have the correct root certs on the device. Either way, the only certificates you can view through the "certificates" screen are the website SSL root certs. You need RapiConfig.exe to dig deeper…

    Next step: If you are still stuck, email me the file and I’ll check it out for you here. email me at daern_at_instantfortress_dot_co_dot_uk if you want me to take a look.

    Good luck!

    Daern

  45. mike edgar says:

    Thanks Daern.

    Yes, we did the re-signing, but it turns out that we didn’t use the privileged root cert.  However, even after using the privileged root cert we still aren’t able to call the privileged API.  We are following up with Geo-Trust support.

    We are using the I-Mate K-JAM PPC device.

    We attempted to run RapiConfig.exe but it doesn’t work as we are blocked from accessing the cert info.  OEM/ROM image settings?

    If Geo-Trust support can’t help we may take you up on the offer ๐Ÿ™‚ and send the file over.

  46. daern says:

    Mike,

    Which API are you trying to use? Does it work ok when the file is unsigned and you have to confirm it?

    I have an O2 branded version of the same device (HTC Wizard) on my desk and that allows me to access the cert info with RapiConfig. As I understand it, the iMate version has the same privileges as the XDA, so it should work…

    Daern

  47. scyost says:

    Mike, PPC devices are one-tier so any application that can run has full access to the system so your API problem is very likely not a signing problem. Does the API call work on the emulator?

  48. Brendan says:

    Hi scyost,

    I have an Exchange 2003 server that I am attempting to sync with my WM 5.0 device. It works 100% fine unencrypted. I have my own CA installed. I followed this guide here.

    http://www.msexchange.org/tutorials/SSL_Enabling_OWA_2003.html

    To the letter. When I try to sync (attempting to get DirectPush working), it says

    "Result:

    Synchronization could not be completed. Try again later."

    The support code is 0x80072F17

    Quite annoying, I’m pulling my hair out!

    Any ideas, please let me know.

  49. jtollert says:

    Brendan, make sure to check your event log on the exchange server.  If you don’t have a frontend server, you cannot require only ssl connections on your web server.  See http://support.microsoft.com/kb/817379/en-us#

    None of the suggested "resolutions" actually solve the problem, you either have to put in another server, downgrade the security of your server implementation by allowing plain text logins, or do some kind of hybrid "not quite so bad" solution where you create a separate exchange equivalent virtual folder and limit the access to that folder.  As far as I can tell the device doesn’t actually make any requests to port 80 on the wire, but the box needs to be unchecked to make this work.

  50. jtollert says:

    forgot to mention that you may also have to install your root CA cert as a cab file on the WM5 device.  See

    http://blogs.msdn.com/windowsmobile/archive/2006/01/28/making_a_root_cert_cab_file.aspx

  51. Cary Lewis says:

    This scheme, and that’s what it is – is unbeleivably counter productive. We should be investing our energy in making these devices smaller, faster, and longer lasting, and in generating applications. Instead we are capriously forced to jump through hoops in order to obtain the priviledge of running our applications. This is terrible.

  52. sly says:

    Hello,

    I am curious about the root certificates for accessing exchange via a Treo 700w.  We purchased a Class 3 from Verisign and I thought we would not have to install the cert on the devices since the Class 3 is one that is built in.  Do you have to install it on the device no matter what, or only if you are creating you own cert and running your own cert server?

  53. Joe says:

    We have an application that runs on WM5.0 (PPC and SmartPhone) devices. There are dozens of DLLs and several CAB files which we have to sign. We’ve been able to do that but (as an earlier poster noted) it is a slow and expensive process. If there were at least a way to automate the signing process with GeoTrust (i.e. via some Web Service) it could at least be automated.

    Does anyone else think it’s crazy that it is a manual process? Does anyone know if there is a way to make this faster?

    Thanks,

    Joe

  54. Samuel says:

    Hi All,

    After reading all the posts above, i still have doubts about the signing issue.

    I have situation here whereby i need to provision all the devices used by the company staff.

    I tried to create a provisioning cab using the cabwiz from visual studio 2005 with the provisioning xml as well as a sample application in the cab file.

    I tested with pocket pc phone and the provisioning setup worked out perfectly with unknown publisher prompt.

    Then i tried by using my company own CA to generate the root cert as well as the codesigning.pfx to sign my cab file in order to support the smartphone version as well. I have tried to install the root cert generated to the smartphone root store using the signed cert installer and tried to invoke the provisioning cab but its stated unsuccessful.

    Is it impossible for us to use our own CA instead of using the M2M  ?

    What if my company constantly want to deploy updated provisioning cab to users ? WIll it need to pay each time i want to sign the new cab ?

  55. joNa says:

    hey i deleted some dll system files on my hp ppc ๐Ÿ™

    ๐Ÿ™ where i can download them ?

    cant install exe files or delete programs or nathing help me post e mail message joniztomaatti@hotmail.com  pm me plz! ๐Ÿ™

  56. scyost says:

    Hi Samuel,

    Certinst installs certificates to the ROOT store, which is not a code execution store. If the unsigned cab won’t install the certificate on the smartphone, you’ll likely need to contact the operator for help unlocking it. Once you can install certificates, just install your corporate codesigning cert to the Privileged and SPC stores, and then you are good to go.

  57. Samuel says:

    scyost,

    Thanks for the information, is there any automate ways to handle this ? why extactly to install the cert to the code execution store ? i noticed that in the windows mobile smartphone cert store, there is only 2 store available, personal and root.

  58. Ian Taylor says:

    Hi all basically we have 25 O2 xda execs which we just cant get to connect to exchange whilst ssl is on we always get error code 0x80072F17, is there a page somewhere on the net that will help once and for all this is crazy, everybody is asking but wheres the answer?

  59. daern says:

    Scott,

    A question about code signing. We have an M2M code signing cert, which we use to sign our (rather complicated) application. Unfortunately, the process for actually getting code signed is a real pain, especially when you have multiple binaries tied into CAB files. It gets even worse when you use (as we do) a continuous build process.

    Would there be any issues with wrapping a corporate code-signing cert into a CPF, signing it as priv. and then deploying that, along with our applications (signed against our corporate cert)? This would allow us to:

    a) Integrate code signing into our build process

    b) Greatly simplify our release process

    c) Reduce cost (by not having to pay Geotrust every time we rebuild a DLL)

    Any thoughts on this?

    Daern

  60. LuisCa says:

    This would violate the M2M guigelines.

    You are not allowed to sign an application that provisions another certificate.

    Thanks,

    -Luis Cabrera

  61. scyost says:

    Daern –

     That’s a good method for corporations deploying line-of-business apps or for internal development but you can’t do it for arbitrary retail devices. We’ve been working on a way to reduce the pain and cost of publically deploying multiple-file applications. I hope to be able to talk about it soon.

     If you have a consistent set of customers then using your own corporate codesigning cert will probably work well – you just can’t use the M2M cert to bootstrap your cert onto the device. You’ll have to add it via the unsigned cab method or via an operator developer unlock program.

  62. Daern says:

    Luis / Scott,

    Thanks guys, good information. It sucks, but it’s still good information ๐Ÿ˜‰

    I’m looking forward to this being sorted and can’t wait to hear your news. The current app signing procedure is awful and anything that can help it can only be welcomed by developers.

    When you have a modular app, built from 10 or more DLLs, changing a single line of code in a shared module can easily waste half a day buggering about with Geotrust’s hateful web interface. And it is, of course, very easy to get it wrong (how was I supposed to know that *all* binaries in the CAB must be signed, even if you don’t use them!?). Certainly, assuming that if the CAB is signed, the app must be too would be a great start…

    Grumble grumble, mutter mutter. Here’s to the future…

    Daern

  63. suroot says:

    Is there a way to install a certificate into the "personal" store for Web browser/e-mail authentication in Windows Mobile 5.0 for Smartphones?  If so how do I do it?  I have tried the pfxinstall from Jacco but it doesn’t seem to work for my phone.

  64. jay says:

    Scott/anyone,

    i’ve tried to install code signing cert to SPC store via operator’s tool and i managed to get the cab signed using code signing cert.

    Everything works fine for pocketpc phone edition, but came to smartphone, which i also installed the cert successfully, its failed to install. i even install the cert into the priv store but no avail.

    Anyone have any idea ?

  65. steve says:

    i also the same problem with jay stated above (smartphone), based on above explaination:

    "Because the certificate doesn’t chain to an execution root on the device. For a binary to be trusted, the cert must chain to a certificate in the Privileged or Unprivileged Execution Authorities stores. A typical Windows codesigning certificate from a CA won’t work. Get a Mobile2Market certificate to run on the widest variety of devices."

    I have an signed operator tools which allow me to launch the provisioning to install the cert into SPC. But since we need chaining, may i know what type of cert need to derive and how’s the cert chaining works such as which type of cert need to put to certain cert store to enable the launch of installation.

    Anyone ? Thanks in advance

  66. Kevin Woram says:

    Is the SelectPictureDialog a trusted API?  When I run my unsigned app on a WM5 iPaq, the app can launch the SelectPictureDialog normally.  On a WM5 phone (Cingular 8125), when my app tries to launch the SelectPictureDialog, it closes immediately with DialogResult = Cancel.

  67. Dmitriy Kurovskiy says:

    The geotrust certificate was working on smartphone for a few months, now it doesn’t. Why???

    How to check whether the needed certificate is in the smartphones certificate list? Is it personal or root?

    May be certificate from geotrust has an expiry date??

  68. Dmitriy Kurovskiy says:

    "Your comment or rating has been received. However, due to caching and moderation, it may not be displayed right away. "

    But why? The other posts doesn’t seem to be moderated at all.

  69. Daern says:

    Hi all,

    Good grief, there’s been a lot of rubbish on this blog recently. Oh well, here’s something real:

    Is DMProcessConfigXML() a privileged API? I can’t see it on the list, which seemed odd. So if it isn’t a restricted API, can I do anything I like with this, even if my app is signed unpriv?

    e.g. delete PPP or GPRS entries, or create new ones

    Suggestions?

    Daern

    ps. the reason I am doing this is because the app that I use to wrap this API is signed against the M2M priv. root, but bloomin’ Orange don’t recognise the priv. M2M root certs, so assume my app is unsigned. So my choice is to a) re-sign the app as un-priv and hope it still works or b) Submit it to Orange for an extended period of poking and fiddling. Obviously a) is easier, if it works…

  70. daern says:

    And while, we’re at it…one more question:

    If a DLL is signed against a priv. root, but loaded by an EXE which is signed against an unpriv. root, what access would functions called from the DLL have?

    i.e. Could I wrap all of my privileged API calls into "privstuff.dll", sign that against the privileged root and then sign the rest of my application as unprivileged, safe in the knowledge that, when I need to call something important, I can do so via privstuff.dll…

    Thanks

    Daern

  71. daern says:

    Dmitriy,

    You can use RapiConfig.exe via Activesync to dump the certificate stores and compare the thumprints of the root certs against the thumbprints of your signed apps…

    Daern

  72. scyost says:

    Hi Daern,

    Those are two good questions.

    1) DMProcessConfigXML has different behavior depending on the caller’s trust level. If the caller is trusted, the XML is processed with SECROLE_MANAGER and it can modify any setting. If the caller is untrusted, the XML gets SECROLE_USERAUTH, which is roughly analogous to the same things an untrusted process can modify. One exception is around the grant manager policy (decimal 4119). If the rolemask for that policy includes SECROLE_USERAUTH (16) then the XML from an untrusted process will gain MANAGER role. Some two tier devices do ship with grant manager set to user auth, so it is a possibility. Explaining where these security roles come from and how they interact is something I’d like to devote a later post to.

  73. scyost says:

    Daern,

    The current trust level is a property of a process. So if an "normal" process loads a DLL that is signed with a cert in the priv store, the code will still be in "normal" execution mode when it calls into the DLL.

    In the opposite case, if a process running privileged tries to load a DLL signed for normal execution, the module load will fail.

  74. Daern says:

    Thanks for the info Scott. Very useful. I had a feeling that DMProcessConfigXML wasn’t a straightforward API…

    I think I’ll probably have to just give it a try and see if the particular settings I need to change are ones that required privileged access.

    Sadly, one of the APIs that is (annoyingly) protected is lineGetGeneralInfo, which we frequently use to read the IMEI of the radio in a GPRS equipped device – our software uses this to key the device into the host system. This unfortunately means that the whole app will need to be signed privileged, just because of this one call, even though the API is only called in one module out of the dozen-or-so that we use ๐Ÿ™

    Daern

  75. Andy says:

    noob question, we have a corporate PKI infrastructure, can we sign our own WM5 apps ? How would we do this ?

  76. Daern says:

    Andy,

    The short answer is "no, you can’t".

    The long answer is "yes, you can, but in practice, you can’t". I’ll try and explain:

    You can, of course, sign your applications yourself using your existing PKI certs. The difficult part is persuading WM5 that it should accept these root certificates as "trusted" and therefore accept your application as signed.

    The certificate stores that hold the root certs are protected to prevent you from placing your own root signing certificates onto the device. There are ways of getting round this – an example would be to wrap the root cert into a CPF and then sign this using the Microsoft M2M program using a "privileged" root. This would then have the correct rights to insert your own root certificate and your self-signed apps would work. Unfortunately, and as pointed out to me a few posts earlier on this page, this is a clear violation of the (exceedingly annoying) license terms of the M2M program.

    Of course, if you’re a mobile operator or hardware manufacturer, you would seem to be free to add your own root certs, or to delete the standard Microsoft ones, thus making life difficult for other developers (*points large rubber finger at Orange UK*) but I assume you don’t come into this category.

    So, there’s your answer. In short, no.

    Daern

  77. scyost says:

    It partially depends on what devices you want to support. For instance, you can use the CAB method to add your corporate certificate to any Pocket PC device. Some smartphone devices are locked by the mobile operators and in that situation it might be impossible to install your codesigning certificate without an agreement with the mobile operator.

  78. Anita says:

    Hi scyost,

    I have already applied for privileged cert, but it can not work. I use cerapiinvoke(runs on PC) to call a dll(runs on PDA), My process is as below:

    1- Request a M2M privileged signing account

    2- Sign the DLL with this privileged account

    3- Provide CabWiz a /postxml XML provision file

    4- Compress everything in a CAB with the provision file

    5 – Still no luck, can get the DLL to work, always getting a E_ACCESSDENIED(0x80070005) in the face…

    Provision file content :

    – <wap-provisioningdoc>

    – <characteristic type="Metabase">

    – <characteristic type="RAPIWindowssetup.DLL*">

     <parm name="rw-access" value="3" />

     <parm name="access-role" value="152" />

    – <!–

    152 maps to "CARRIER_TPS | USER_AUTH | MANAGER"

     –>

     </characteristic>

     </characteristic>

     </wap-provisioningdoc>

     </wap-provisioningdoc>

    My dllโ€™s name setup.dll and in folder windows

    Do I miss anything?

    And I can not set system attribute to my dll by using CeSetFileAttributes, the return value is always False, why?

    Thank you very much for your help.

  79. DevOne says:

    In regards to:

    "Is the SelectPictureDialog a trusted API?  When I run my unsigned app on a WM5 iPaq, the app can launch the SelectPictureDialog normally.  On a WM5 phone (Cingular 8125), when my app tries to launch the SelectPictureDialog, it closes immediately with DialogResult = Cancel."

    While it seemed a little off topic, this is an API that does seem broken.  We’ve seen the picture picker fail all the time on some devices, most of the time on others, and work just fine on others.

    From our testing, I don’t think it’s a trusted API, I believe it may have something to do with if the appropriate DLL can loaded into memory at an specified location.

  80. scyost says:

    re: SelectPictureDialog – it’s not a trusted API as far as I know. Even if it were, it wouldn’t be a problem on the 8125. That’s a PocketPC, so any code that runs will run with full trust.

  81. scyost says:

    Anita –

    CeSetFileAttributes can’t set the SYSTEM attribute  by default. The cab that installs your application can add the SYSTEM flag to the DLL at install time. If SYSTEM isn’t getting set correctly, that is probably why the call is failing.

  82. Michael says:

    Q: Does Windows Mobile support wildcard certificates?

    A: Not in the current versions.

    Does this mean there might be an "update" to WM5 to support this or is this going to be a major update such as WM6?

  83. scyost says:

    Wildcard support isn’t currently slated for any WM5 upgrade. I can’t comment on anything past that until it’s public.

  84. ivarklung says:

    I have a very important question regarding the implications of WM 5.0 Security Model and Free and/or Open Source (OSS) Software.

    We ourselves develop several FREE/OSS Software.

    The requirements for code signing through Verisign or GeoTrust puts an enormous economic burden on our projects.

    To quantify: Each of our language versions of our 4 different systems are updated/released on almost a monthly basis and contain 10-20+ dll and cab files EACH! This means we will have a monthly expense of about 1500 USD per month, totalling to 18 000 USD per year! That is not taking into account all the time/cost associated with signing every single file manually through i.e. VeriSign.

    As you can clearly understand this is totally unacceptable for us!

    What solution will you/Microsoft suggest for this kind of development group?

  85. scyost says:

    Hi ivarklung – it’s the same as for everybody else. If you need to run without a prompt on the widest variety of devices, go through M2M. Depending on your app, you can probably run unsigned on Pocket PC devices or on some Smartphones if you want to save the money.

  86. tomsft says:

    I think the whole security scheme is a scamp to get more money out of people pocket. VS 2005 is like a gaming console without any game.

    Why there’s no concrete article about deployment scenarios. All Microsoft want to do is make people follow their way of doing thing.

    I spent a lot of time developing application. And now I’m stucked because i can’t deploy them.

    Any article about windows deployment and security is very sketchy and incomplete with full of theories. They tell you by doing this way everything should work. but in the end after understanding all the mecanism of generating certificate and code sign applications you realize that nothing is working and there’s more to learn.

    So to make things easier as Microsoft will say, you need to spend money on Market 2 market certificate. They say they don’t have any business in that but why they have already those certificate preloaded into all windows mobile devices. Some how along the line they are making money there.

    So my question is when will microsoft release a complete bible about security and deployment?

  87. ivarklung says:

    Hi scyost

    Thanx for a clear answer!

    But come on, you can’t recomend running it unsigned! You know very well that that is going to be problematic as more and more devices are shipped with the higher security configurations. SO THAT IS NOT A SOLUTION!

    Do you agree that this basically will limit the possibility of open source / free software on WM 2005 devices (with some level of security)? That is of course as long as you don’t have a comercial branch or a rich uncle who would like to support you.

    Or is this a sacrifice that MS is willing to do in order to satisfy OEMs and Mobile operators?

    I strongly urge you to find an alternative signing method for none-commercial software.

    We are developing software for usage primarily in low-income countries for health and development research.

    I think this is something that needs to be taken up to a very high level within MS!

    This is a case that really needs your attention, even though OSS is not MS favourite friends. We are not talking about Linux or competitive systems, but systems made to run on your own OS.

    I trust that you will take my question / challenges seriously.

    Thank you for your kind assisstance!

    Best regards,

    ivar

  88. scyost says:

    I can agree that it limits the possibility of any software that doesn’t have a corresponding income to pay for signing. The operators choose how to deploy their phones, and they are very interested in restricting the software that runs on their network. If you want to run whatever you want on your phone, the best way to do it is to buy a device that’s not restricted by the operator.

  89. sngo says:

    what is the difference between .cer and .spc. It seems like we can interchange them any time except for signcode which only works with .spc.

    Thank you

  90. scyost says:

    As I understand it, a SPC can contain more than one certificate while a CER is only one. I’ve found that you typically need to use the SPC to sign because otherwise there’s not enough chaining information in the signature for the device to verify the complete certificate chain up to the root.

  91. ivarklung says:

    Refering to above discussion about non-commerical actors and code signing.

    You suggest to buy a device which is not restricted by the operator. I can’t ask all my users to buy a specific model, and I don’t even know of a model that is not restricted in any way. I though that was part of the M2M?

    I’m getting quite confused. My own device I can always manage to hack to get around the signing, but I can’t advice my users to do the same thing.

    I still think that the solution could work for commercial software, but for non-commerical actors it is a NO-GO!

    And I strongly urge MS to find an alternative deployment path for non-commerical actors.

  92. ivarklung says:

    I recently read that VeriSing has purhased GeoTrust. So now there is in principal only one company capable of issuing certificates to the WM05 platform.

    Does this mean that other authorities are coming in?

    Thanx,

  93. scyost says:

    I don’t know of any other authorities scheduled at the current time.

  94. I&#39;ve plugged a new Windows Mobile 5 device to my dev box and tried to deploy and debug a simple Compact

  95. Andy Jones says:

    If I just want to sign my WM5 apps with a certificate and then place that certificate on all the devices that will ever run that app (I have this luxury – it’s not an app for public use), then I don’t need M2M, right? I just need to get a Verisign Authenticode cert, install it onto the priv store of all our PPC WM5 units and then sign our apps with it? Is that right?

  96. scyost says:

    @Andy: Yes, you can do it like that. It doesn’t even have to be a Verisign ACS cert.

  97. Andy Jones says:

    Cheers for the help scyost.. but your answer brings another question.. If it doesn’t have to be a Verisign ACS cert.. what else can it be? We’re keen not to use the developer certs, even though I believe we could. Thanks.

  98. socal says:

    Hey there,

    I would really like someone to comment on the following.

    We have been shipping properly signed Smartphone applications since fall 2002.

    This is to say that we do have some years of experience with this whole signing thing, and we have been going thru the signing process for every release of most of our applications (now including some PPC apps).

    Now, recently, we released a new unprivileged Smartphone app, which we signed (as usual) using GeoTrust.

    And we started getting strange feedback from people unable to install it on their phones.

    Guess what?

    It appears that it actually won’t have any chance to install on some 2003 and earlier Smartphone, because the signature is not recognized as valid.

    How is this possible if it’s properly "M2M signed" and it is correctly recognized on other phones with no security prompt of any kind?

    Because NOW (we don’t know exactly when this started) the signatures applied by GeoTrust reference a root GeoTrust certificate that doesn’t actually exist on all devices (it would be nice to know of course)!

    We compared different files and CABs that we signed with GeoTrust in the last year or so. And, we can say for sure, that until MARCH 2006 (that’s last year) the signatures applied by GeoTrust referenced a Baltimore root certificate, which is the root certificate actually available on ALL DEVICES.

    But now, (for sure, since last August) the so-called M2M GeoTrust signature points to a "GeoTrust root" that’s only available in RECENT DEVICES (how recent they have to be, of course, it’s not known).

    This means that the whole assertion in this post, that non-privileged apps signed with a M2M certificate will run on ALL Smartphones by all operators (except SKT), is NO LONGER TRUE and should be revised accordingly, possibly including all the messy details about how and when this change took place, and what devices are affected (because they don’t have the GeoTrust root), so that developers can actually have an idea of who can install what and who cannot.

    In other words, if not clear, apps signed with an unprivileged M2M certificate prior to a given date (we don’t exactly when, for sure up to March 2006) do actually install and run on all Smartphones by all operators (except SKT).

    But a new release of the same app signed today will not install on Smartphones that do not have the GeoTrust root certificate installed.

    If this is bad for developers, just think at the frustration from the point of view of end-users: a customer of mine that has always used my app cannot install my latest release (even if I took the pain to apply the M2M signature), because he doesn’t have the GeoTrust root certificate on his device. How nice, huh?

    So, given the "state of the art", here are my questions.

    First of all, of course, given all the confusion already existing on this matter, why add some further mess?

    This is just curiosity, but I would really like to know… There must be a very good reason, I hope.

    Second question: why no mention of this on any of the M2M pages on the Microsoft site, on the GeoTrust site, or on other Microsoft support pages like this one? Didn’t anyone know about this?

    I cannot believe it!

    Third question: how about preparing a nice CAB (referencing the old Baltimore root so it can be installed on any device) which installs this new GeoTrust root certificate (and any other recent ROOT), so that developers can at least point their existing customers to this resource and allow them to upgrade and/or install their latest software?

    Or how about GeoTrust providing an option to actually sign binaries and CABS with the old signatures (pointing to the Baltimore Root), which are the only ones having a chance to be recognized and accepted by all devices?

    Last but not least: do you think it’s fair to have developers going through the pain, confusion and associated costs of all this signing thing, and then end up with such an unpredictable result, having to discover issues like this by themselves, and even then, having no idea whatsoever of who will actually be able to install the software and who will not?

    Is this what Mobile2Market is all about?

  99. scyost says:

    Hi Socal,

    I’m sorry that you encountered this frustration. I am routing your concern to the M2M and contacting Geotrust right now.

    Scott

  100. socal says:

    Thanks scyost.

    I think that a better understanding of the situation would indeed help to clarify the matter, and provide *actual* information to developers visiting this and other related pages.

    By the way, if helpful, examining cabs signed with GeoTrust until last March, they were marked as follows:

    "GeoTrust Windows Powered Mobile Device CA 2"

    and the certification path pointed to:

    "Baltimore Mobile Device Root"

    (valid from 4/1/2002 to 4/1/2022)

    On the other hand, cabs signed after August 2006 are marked as follows:

    "GeoTrust Mobile Device CA – UnPrivileged 1"

    with the certification path pointing to:

    "GeoTrust Mobile Device Root – Unprivileged"

    (valid from 7/29/2003 to 7/29/2023)

    After hearing reports from various customers, we did some investigations with RapiConfig on the root certificates actually available on a few phones we have here.

    We found that the "Baltimore Root" is ALWAYS installed (from the earliest devices to WM5 devices and emulators), while the "GeoTrust Root" is not available on some WM2003 and earlier devices.

    My guess is that (probably?) only 2003/SE devices (and greater) have this installed… but, of course, it would be very nice to know something for sure…!

  101. socal says:

    BTW: scyost, if you look at the comments above, you will find an item posted on Sep. 19th, 2006 by Dmitriy Kurovskiy (who didn’t receive any answers). I think he was probably writing about this very same issue. He was aware that something was "different" and "not working anymore" with the GeoTrust signature, but didn’t know exactly what.

    I guess other developers have probably encountered the same problem (or received feedback from customers due to this issue), but have simply "swallowed" the problem as another "unknown mystery" of the M2M signing process.

  102. Tim Meggison says:

    Hi all,

    I have recently inherited the Product Manager responsibilities for the GeoTrust & Verisign code signing services, and have been investigating this issue.

    There were some contract issues in early 2006 that resulted in GeoTrust no longer being allowed to use the Baltimore Mobile Device Root.

    An email notice was sent to all customers on April 27, 2006 indicating our change in roots.  The email notice identified the new root and indicated the new root was compatible with Microsoft Windows Mobile 5 and SmartPhone 2003 devices.

    The GeoTrust web site was also updated so that new customers would know that the GeoTrust M2M service was compatible with Microsoft Windows Mobile 5 and SmartPhone 2003 devices.

    So – that is the history of events based on the information I have been able to gather.

    Based on some of the entries here, it appears that either the email notice was not delivered correctly or did not convey the correct information.  In regards to the information on the GeoTrust web site – what better terms or phrase should be used to identify device support?

  103. socal says:

    Tim,

    no need to play it on the defensive: my point was simply that *maybe* (but it seems from your message that I may be wrong) there’s not that much information about this "change" and some of its implications, and I have the impression (but again I may be wrong) that "downplaying" the whole thing doesn’t help to improve the situation.

    I would say that both the reaction of who manage this blog, and the fact that you (current PM at GeoTrust for this area) had to "investigate this issue" tells a lot about the very little information surrounding all this. If it’s like that for you, think how it is for your customers… ops, "the developers", huh?

    Yes, indeed it seems that all WM5 devices have the GeoTrust root installed. But the impression we have is that the situation with earlier devices is not so clear-cut as you make it. And the term "Smartphone 2003" may be misleading: two "Smartphone 2003" devices we have here don’t have the GeoTrust root installed, and the ones that have it are actually WM2003/SE. Of course, we don’t know if this can be taken as a "rule" or not, and that’s exactly the reason why I posted my first message, complaining about the "lack of information" on all this, and suggesting that someone would better clarify this matter.

    But, I understand from your message that my comments were inappropriate and out of place: everybody – except me – was perfectly informed and well aware of this issue and all of its implications (Smartphone 2003?). There was "an email notice sent", and "the site was also updated so that new customers would know"…

    I did check my archived email, and I indeed found a message from GeoTrust on this (for a total of 7 lines of text). And you are absolutely right: the message was dated "April 27th, 2006", probably to inform people with a reasonable advance and give them some time to think about it. Here’s what it said:

    >> As of April 26th (so it had already happened!) we have changed the certificate chain used for the Mobile2Market unprivileged signing service. The new certificate chain will contain the following Root and Subordinate CA.

    >> ** GeoTrust Mobile Device Root – Unpriviled ** GeoTrust Mobile CA – UnPrivileged 1

    >> The new root hierarchy is compatible with Microsoft Windows Mobile 5 and Smartphone 2003 devices.

    Aside for the doubts I expressed about "Smartphone 2003" compatibility (please note that "Smartphone 2003" and "Windows Mobile 2003" are different beasts, as the latter implies "SE" aka Second Edition), it is indeed my fault if I didn’t pay enough attention to such a clear message.

    Maybe something like "it is compatible *ONLY* with" would have helped me to turn on my brain and start thinking of the possible implications hidden in that sentence.

    And for sure, a sentence like "the new signature won’t be recognized by earlier devices or by any device that for whatever reason doesn’t have the new GeoTrust root installed" would have made the importance of the change, and its implications, just a little bit clearer! Just a little bit…

    The same applies for the GeoTrust web site. If I login to sign an app, I don’t read the "Features and Benefits" box in your M2M front page. And even if I did read it, a marketing line saying "Add protection to your applications on MS Windows Mobile 5 and Smartphone 2003 devices" doesn’t necessarily make me think that something has changed, and that the signature I get now won’t be recognized by earlier devices (plus the doubts I expressed about Smartphone 2003). Aside for the marketing blurb I just quoted, I didn’t find a single line anywhere on the GeoTrust web site (including the FAQs) mentioning that the signature is recognized *only* by WM5 and 2003 (?) devices, or mentioning any kind of potential problem or compatibility issue with devices that, for whatever reasons (2003?), have only the previous root certificate in place.

    For someone who’s been signing applications with GeoTrust for years having to find out of all this almost by accident is quite disappointing. But as your message implies, everyone was perfectly informed, so the whole issue probably applies only to me and to whoever posted a message on this same blog on Sep. 19, 2006 about the GeoTrust signatures "not working" anymore (and there was so much "awareness" of this issue that his question remained unanswered…).

    One final note: I’ve seen that all GeoTrust roots (including the one we are speaking of) are available for download somewhere on the GeoTrust web site. And this is indeed a very nice initative that you have in place. But I also know that a root certificate cannot be simply downloaded and installed on any Smartphone device. And I guess this is consolidated knowledge here.

    So, did anyone ever considered creating a simple small signed CAB file to help people getting the latest GeoTrust root certificate installed, and/or invite operators to make such a resource accessible on their support web sites (or to create themselves such a resource in the few cases where this was actually needed)?

    That’s something I would have expected from GeoTrust and/or whoever takes care of the M2M initiative at Microsoft. But I have the impression (and the so-called "notice" sent by email, and the "updated web site" make this impression even stronger), that whoever was in charge of this at GeoTrust was so busy to minimize the relevance of the change, and its implications, that such an obvious initiative looked like the last and worst thing to do.

    With the result that there’s no installable ROOT certificate, and no information AT ALL *ANYWHERE* describing this.

    Oh, Well… except fot the current discussion on this blog.

    Jeez, I’m so sorry: next time I’ll keep my mouth shut, huh?

  104. scyost says:

    So here’s the deal. There are three M2M code execution roots: Verisign, Baltimore, and Geotrust. The Verisign and Baltimore roots date back to the ’02 release. The Geotrust root cert was added later, in an AKU between the 2003 release and the 2003SE release. I believe all the 2003SE devices will have all three certs. The Geotrust signing program switched over to using the Geotrust root in 2006 like Tim says above. So if you’re getting signed via that program, your code won’t run out of the box on ’03 and ’02 devices. I’ll add another entry up above that makes that more clear.

    We have actually been investigating the solution you describe of providing a CAB file so users can install the Geotrust cert on the downlevel devices. I doubt I could convince the operators to do it since those devices are probably out of support now, but we can sign it so it’s installable by the end users.

    Again, I apologize for the inconvenience that you’ve encountered. Thanks for bringing it to our attention.

    Scott Yost

  105. socal says:

    Thanks Scott.

    That seems to confirm our findings: 2002 and 2003 are out, 2003/SE and WM5 are in.

    As someone used to say: "information is power".

    As for the installable GeoTrust root certificate (via a signed CAB file), I know that it may appear time wasted now, but I think that it may still be worth the effort.

    I understand perfectly that, with WM6 devices coming soon, Microsoft, OEMs and operators are not very sensible to something related to 2003 devices (though, with proper information, they would have probably been quite sensible just one year ago, when this change occurred, and WM5/Smartphones were just starting to hit the market).

    If you just think back of this very same period one year ago (no MotoQ, no SmartFlip, no BlackJack, etc.), most operators were actually still selling and trying to get rid of their stock of 2003 devices. So, given the kind of contracts often attached to phones, the number of people still using a "2003" device should not be underestimated.

    There are plenty of a 2003 devices still in use out there, and there are people who bought such a device less than a year ago.

    So, having such an installable GeoTrust root, would at least help us (developers) to deal with whoever is having problems installing our recently signed software on their phones.

    Instead than telling strange stories about signatures, security, compatibility, or, plainly, that the phone they bought last year is already way too "old", we could simply point them to this installable GeoTrust root and make everybody happy.

    If anyone actually takes care to create an installable signed CAB file with the GeoTrust roots, and it it doesn’t complicate things, it would be great if both the the unpriv and priv GeoTrust roots could be included, so the whole issue would be addressed once and for all.

  106. Karun Bakshi says:

    Hi,

     I am trying to sign my binaries using ACS from Verisign. When I try to install the files on the WinMobile 5 device, I am told the publisher is unknown. It seems the root certificates that are installed are for SSL. What about root certs for ACS? Where/how do we install them on the device so that it recognizes the signed content as being from a particular vendor? Thanks!

  107. scyost says:

    @Kiran: Check out the first question under codesigning above. Did you go through the Mobile2Market program?

  108. Vignesh P says:

    Hi All,

       Just take this instance. I have created a new CAB for my application with .exe and some .dll files. This is a signed cab and all the executables and dll’s in this CAB are signed. I would load .dll libraries from .exe everytime.

      If the library is not signed or unprivileged one, it will not be able to load from signed privileged .exe.

      My other scenarios are as follows. If an intruder tries to,

    1. Replace my M2M signed abcd.dll with older version of abcd.dll

    2. Replace M2M signed abcd.dll with a M2M signed wxyz.dll renamed as abcd.dll

    3. Replace M2M signed abcd.dll with a other party signed 1234.dll renamed as abcd.dll

    What will happen in these scenarios?

    My guess is,

    3. This one will not be able to run on the device as it is not signed with M2M certificate.

    2. When I am trying to access certain API’s in this library, it might fail and error will be thrown.

    1. I am not sure abt this scenario.

    Can anybody resolve my queries.

    Regards,

    Vignesh P

  109. scyost says:

    Hi Vignesh,

    Thanks for the question. This is the kind of question I enjoy answering. ๐Ÿ™‚

    The answers to your questions really depend on the security policies of the device. I’m assuming your files are signed for M2M privileged mode.

    1) If the older version of abcd.dll is also signed M2M Priv, it will load fine.

    2) The DLL will load. If you try to dynamically call into a DLL export that doesn’t exist, your program will fail or crash.

    3) Here it depends on the security policies. I’m assuming the signing certificate is one that is not on the device, so the DLL is effectively unsigned. On a two-tier device (typical Smartphone), your EXE will have trust level 2. The DLL will get either trust level 1 (if user lets it load via prompt) or level 0 (if unsigned code is disallowed or blocked by user). In either case, it won’t load into the process.

    On a one-tier device (typical Pocket PC, some Smartphone) the answer is different. If the DLL passes the prompt, it will get trust level 2 and it will load into your EXE.

  110. Vignesh P says:

    Thanks scyost for your cool replies.

    "Replace my M2M signed abcd.dll with older version of abcd.dll"

      In this scenario, how can I avoid loading older version of dll? My requirement is, once my application is installed on the device and if a intruder tries to replace the existing dll with older version of the same dll it should not load that dll and throw some error.

      Same is expected in other scenarios too. In 2nd and 3rd scenarios too, it should not load that corresponding dll and throw error message.

      Is it possible to do so? If that is possible how can we do it? How to stop the corresponding DLL’s from loading? Is it possible to have any config files with DLL versions or checking identity of the particular file?

  111. ChadAmberg says:

    If you are looking for just internal corporate application delivery, mobile2market is overkill.  The answer would be deploying your Corporate CA root to all the handhelds, and signing with an internal code signing certificate.

    To make this easier check out http://www.digitallabs.net/mcb

  112. Okay, I promised this would be my next blog post, but had to push the security primer to help get us

  113. David Linker says:

    I have a simple application, a type of calculator, with one EXE. I want to get rid of the "publisher unknown" prompt during install.

    I have gone through all of the hoops with GeoTrust, signed the EXE, uploaded it, put the re-signed EXE in a cab file, signed the cab file, uploaded to GeoTrust, and then install the re-signed cab file. I still get the "publisher unknown" on an HP iPaq running Windows Mobile 5.0.

    Geotrust tells me that in order to get rid of this, I have to install another installer program on each target machine, and use that to install two additional certificates before I install my program! Of course, when I install that installer program, I get the prompt I was trying to avoid.

    Is this correct? Is it necessary to intall additional certificates to get this to work at all? If not, where do I start debugging. I have examined the files that come back from GeoTrust, and each has a digital signature from GeoTrust. What else should I check?

    Thanks in advance

  114. scyost says:

    Hi David,

    That doesn’t sound right. Signing the EXE and CAB with the M2M certs should be sufficient. Check out this post : http://blogs.msdn.com/hegenderfer/archive/2007/06/13/when-good-signatures-go-bad-part-2.aspx that has more detailed troubleshooting steps for this including the hashes of the M2M certs (to make sure you have the right steps). You can send me a mail if you have further problems – click through the link to my profile to contact me.

  115. gerekbolsa says:

    Hi I have java midlet signed with thawte code signing certificate. But when I try to install my application in my device(T-Mobile MDA with Windows mobile 5.0) it refuses to install saying "Unable to verify digital signature", but I can see the root certificate in my device.

    The same application successfully installs in my Nokia 6630 device with no complain.

    Do you have any suggestions, please help.

  116. Anna says:

    I thought developing and deploying windows mobile apps was easy. I was wrong. I thought windows mobile would beat Blackberry in the future (since it was hardware independant), I may be wrong again because of the strangely complicated and inconsistent process.

    Can’t Microsoft learn from how RIM handles code signing??

  117. barny short says:

    Is there any way of disabling the check for a signed exe being started on a pocketpc /WM2005 / dell aximx50 device each time the unit is reset ? We have no need for it and each time i reset the device it comes up with this ‘publisher unknown’ message that potentially allows the user to compromise the security of the unit. How can  a feature that reduces the security of a device be sold as a ‘security feature’ ?!? Never had this problem with pocketpc / mobile 3 / Symol MC50.

  118. Craig says:

    I am extremely confused.  We simply want to connect our Windows Mobile Smart phones to our exchange 2003 server to use activesync wirelessly.  No matter what we do we get errors when trying to connect.  I thought this might be an easy answer but after reading this page I am more confused than ever!  

    Is there a page that can walk me through this in simple terms?  What we want to do shouldn’t be complicated since our Treos running palm are syncing fine.  Seems ironic to me that Palm can sync with Exchange but Windows can’t…

    Please help!

    Thanks!