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
- Anonymous
December 17, 2005
"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. - Anonymous
December 18, 2005
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. - Anonymous
December 19, 2005
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. - Anonymous
December 20, 2005
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. - Anonymous
January 11, 2006
The comment has been removed - Anonymous
January 24, 2006
The comment has been removed - Anonymous
February 03, 2006
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 - Anonymous
February 03, 2006
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?
- Anonymous
February 03, 2006
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) - Anonymous
February 07, 2006
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? - Anonymous
February 08, 2006
Jamie:
Make sure every binary executable in the cab is signed. That means every DLL, EXE, CPL - anything that gets executed. - Anonymous
February 18, 2006
The comment has been removed - Anonymous
February 20, 2006
The comment has been removed - Anonymous
February 21, 2006
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. - Anonymous
February 21, 2006
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 - Anonymous
February 22, 2006
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 - Anonymous
February 28, 2006
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. - Anonymous
March 03, 2006
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 - Anonymous
March 05, 2006
Why is it that all my dll wont install and my remove programs list is empty though the app still lanch? - Anonymous
March 08, 2006
Exchange Server 2003 SP2 - Windows Mobile 2005----------------------------------------------
Microsoft... - Anonymous
March 16, 2006
The comment has been removed - Anonymous
March 16, 2006
The comment has been removed - Anonymous
April 02, 2006
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 - Anonymous
April 03, 2006
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. - Anonymous
April 03, 2006
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 - Anonymous
April 03, 2006
Kochise,
What does your CeRapiInvoke call looks like? Did you give it the full path to your DLL on the device?
Thanks,
-Luis. - Anonymous
April 03, 2006
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 - Anonymous
April 04, 2006
The comment has been removed - Anonymous
April 12, 2006
The comment has been removed - Anonymous
April 12, 2006
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 - Anonymous
April 12, 2006
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, - Anonymous
April 12, 2006
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. - Anonymous
April 12, 2006
The comment has been removed - Anonymous
April 14, 2006
The comment has been removed - Anonymous
April 18, 2006
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. - Anonymous
April 18, 2006
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? - Anonymous
April 19, 2006
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. - Anonymous
April 19, 2006
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 - Anonymous
April 20, 2006
The comment has been removed - Anonymous
April 20, 2006
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? - Anonymous
April 20, 2006
I can confirm that this has fixed my problem with these two CABs. Thanks very much. - Anonymous
April 25, 2006
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? - Anonymous
May 01, 2006
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 - Anonymous
May 02, 2006
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 - Anonymous
May 02, 2006
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. - Anonymous
May 04, 2006
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 - Anonymous
May 05, 2006
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? - Anonymous
May 16, 2006
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. - Anonymous
May 19, 2006
The comment has been removed - Anonymous
May 19, 2006
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 - Anonymous
August 03, 2006
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. - Anonymous
August 07, 2006
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? - Anonymous
August 09, 2006
The comment has been removed - Anonymous
August 09, 2006
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 ? - Anonymous
August 10, 2006
The comment has been removed - Anonymous
August 11, 2006
The comment has been removed - Anonymous
August 13, 2006
The comment has been removed - Anonymous
August 14, 2006
The comment has been removed - Anonymous
August 14, 2006
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 - Anonymous
August 15, 2006
This would violate the M2M guigelines.
You are not allowed to sign an application that provisions another certificate.
Thanks,
-Luis Cabrera - Anonymous
August 16, 2006
The comment has been removed - Anonymous
August 16, 2006
The comment has been removed - Anonymous
August 22, 2006
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. - Anonymous
August 28, 2006
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 ? - Anonymous
August 29, 2006
The comment has been removed - Anonymous
September 07, 2006
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. - Anonymous
September 11, 2006
Thanks for the great tips about <a href="http://eteamz.active.com/cashback/files/bad-consolidation-credit-debt-loan-people.html"">http://eteamz.active.com/cashback/files/bad-consolidation-credit-debt-loan-people.html" title="bad consolidation credit debt loan people">bad consolidation credit debt loan people</a> and [URL=http://eteamz.active.com/cashback/files/bad-consolidation-credit-debt-loan-people.html]bad consolidation credit debt loan people[/URL] - Anonymous
September 18, 2006
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?? - Anonymous
September 18, 2006
"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. - Anonymous
September 28, 2006
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... - Anonymous
September 29, 2006
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 - Anonymous
September 29, 2006
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 - Anonymous
September 29, 2006
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. - Anonymous
September 29, 2006
The comment has been removed - Anonymous
September 29, 2006
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 - Anonymous
September 30, 2006
noob question, we have a corporate PKI infrastructure, can we sign our own WM5 apps ? How would we do this ? - Anonymous
October 01, 2006
The comment has been removed - Anonymous
October 01, 2006
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. - Anonymous
October 03, 2006
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.
Anonymous
October 16, 2006
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.Anonymous
October 19, 2006
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.Anonymous
October 19, 2006
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.Anonymous
October 30, 2006
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?Anonymous
October 31, 2006
Wildcard support isn't currently slated for any WM5 upgrade. I can't comment on anything past that until it's public.Anonymous
November 09, 2006
The comment has been removedAnonymous
November 11, 2006
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.Anonymous
November 14, 2006
The comment has been removedAnonymous
November 14, 2006
The comment has been removedAnonymous
November 17, 2006
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.Anonymous
November 29, 2006
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 youAnonymous
November 29, 2006
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.Anonymous
December 11, 2006
The comment has been removedAnonymous
December 11, 2006
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,Anonymous
December 17, 2006
I don't know of any other authorities scheduled at the current time.Anonymous
February 03, 2007
The comment has been removedAnonymous
February 28, 2007
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?Anonymous
February 28, 2007
@Andy: Yes, you can do it like that. It doesn't even have to be a Verisign ACS cert.Anonymous
March 01, 2007
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.Anonymous
March 11, 2007
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?Anonymous
March 12, 2007
Hi Socal, I'm sorry that you encountered this frustration. I am routing your concern to the M2M and contacting Geotrust right now. ScottAnonymous
March 13, 2007
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...!Anonymous
March 13, 2007
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.Anonymous
March 14, 2007
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?Anonymous
March 15, 2007
The comment has been removedAnonymous
March 15, 2007
The comment has been removedAnonymous
March 16, 2007
The comment has been removedAnonymous
March 23, 2007
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!Anonymous
March 23, 2007
@Kiran: Check out the first question under codesigning above. Did you go through the Mobile2Market program?Anonymous
April 23, 2007
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,
- Replace my M2M signed abcd.dll with older version of abcd.dll
- Replace M2M signed abcd.dll with a M2M signed wxyz.dll renamed as abcd.dll
- 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,
- This one will not be able to run on the device as it is not signed with M2M certificate.
- When I am trying to access certain API's in this library, it might fail and error will be thrown.
- I am not sure abt this scenario. Can anybody resolve my queries. Regards, Vignesh P
- Anonymous
April 24, 2007
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.
- If the older version of abcd.dll is also signed M2M Priv, it will load fine.
- The DLL will load. If you try to dynamically call into a DLL export that doesn't exist, your program will fail or crash.
- 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.
Anonymous
April 24, 2007
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?Anonymous
May 13, 2007
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/mcbAnonymous
May 29, 2007
Okay, I promised this would be my next blog post, but had to push the security primer to help get usAnonymous
June 16, 2007
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 advanceAnonymous
June 18, 2007
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.Anonymous
June 19, 2007
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.Anonymous
August 01, 2007
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??Anonymous
August 16, 2007
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.Anonymous
November 29, 2007
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!