Scam or just a PITA; you decide….
My company ships an application which runs on the PocketPCWindows Mobile platform, using .NET Compact Framework. When we tested it on Windows Mobile 5, we saw a security error since the application was unsigned. Well, no problem, we have a code signing certificate, so we can sign it, right? Nope; that won’t do the trick, for reasons I’ll explain later in this post. No, you need a special certificate from, well, from exactly the same people, only with this one they charge you every time you use the thing instead of just when they issue the cert. Microsoft calls this "mobile2market." "Every time you use the certificate" means "every time you sign a file," so if your CF app ships with one EXE and eight DLLs, you get dinged for nine "code signing events" every time you need to ship a new release.
Generally when you sign an executable or get a certificate for a web server you get it from either VeriSign or Thawte since their certificates are in the root stores of most of the places that matter: Browsers, QuickBooks integration, Java, etc. VeriSign owns Thawte, and Thawte certs are accepted by just about everyone who accepts VeriSign, so if there’s a difference between these companies other than price (Thawte is significantly cheaper), I haven’t found it. With mobile2market the two choices are VeriSign or GeoTrust and if you have to guess more than once as to who just bought GeoTrust then you’re not cynical enough to work in this industry. GeoTrust’s certificates are, not surprisingly, functionally identical to VeriSign’s except that they seem to be cheaper.
Now the cost by itself is not unbearable, at least, if you’re not producing freeware/open source tools. The "events" cost about $10 on the high end and significantly less if purchased in bulk. Of course, you just have to know that since you won’t find the information on GeoTrust’s site. The real problem with this scheme is that the "code signing event" based pricing means that you really can’t do the signing as part of an automated build process. Not just because of cost, although even a few bucks per file signed can add up quickly with daily builds. No, the real impediment is that in order to enforce this "per-use" scheme you are not allowed to sign the files yourself. You have to submit them to a web site, using a machine equipped with a USB dongle which they send you along with your certificate. The certificate they send you, you see, merely allows you to access the web site, not actually sign a file. There may be a way to automate this, although we haven’t found it yet. In any event, you’ll still have to decide when a file needs to be signed, since you probably don’t want to be burning through signing events every day on unchanged code, which is a dimension I don’t presently have to deal with in our daily build routines.
In an ideal world you’d sign only the code you wrote. But since Windows Mobile 5 is fairly new and since the mobile2market signing is either a scam, a PITA, or just idiotic, depending on your point of view, many third-party libraries aren’t signed yet. So if you use any third-party controls in your Windows Mobile apps, you have two choices: Sign your own apps, but not the third-party libraries, in which case your customers get the security warnings you’ve been trying to avoid in the first place, or sign the third-party assemblies yourself. And since component vendors in MS Visual Studio-land frequently don’t even give you the option of obtaining source code, you can pretty much cross your fingers about what you’re signing.
As to why this is necessary in the first place: Turns out that regular Verisign certs don’t count as being from a trusted authority insofar as Windows Mobile 5 is concerned because they’re not in the root cert store when the devices are shipped, even though Verisign mobile2market certs are in the root store. How convenient for companies who would rather charge per use rather than per cert. You can add certs to the root store yourself if you can get a signed application from the device vendor to do it. In other words, you need one app to add your cert to the root store for a Dell device, another for an HP, etc. You might want to do this if you want to, you know, run your software as you work on the code without seeing multiple security warnings every time you run your app and without burning through pay-per-signing events. But you probably can’t redistribute these applications (I haven’t checked), and given the diversity of devices on the market it’s impractical for people selling to the open market rather than selling apps preinstalled on a device you also sell. So mobile2market is really the only choice for people who want to sell applications to the general Windows Mobile market.
{ 8 } Comments
Sounds like a vendor imposed development tax. The kind that kills development and then the platform.
I developed an application for Blackberry (using Java an JDE) and to deploy It you need to sign it every time you canghe your code and recompile It (you must pay RIM just one time to receive the certificate).
So It seems a common approach for mobile devices.
Bertoncini, it doesn’t bother me that I have to sign before I deploy. It bothers me that (1) I can’t sign the code myself; I have to ship the EXE to a third party, and (2) doing so adds no security whatsoever, AFAICS, (3) I have to pay each time I sign any file, and (4) 2 & 3 mean I can’t do fully automated builds.
This seems very different than what you have to do for the Blackberry.
Outrageous. I see that Microsoft wants to drive the developers away from it’s mobile platform in droves.
GeoTrust just quoted $295 for a 10-pack of signing events, so I’d certainly appreciate knowing where to find the $10 per event pricing you mention.
The Rant… Imagine four complementary products targeting Pockcet PC 2002, Pockcet PC 2003, Windows Mobile 5, and SmartPhone versions of the latter two platforms. To eliminate the complexity of creating every possible combination of four products (there would be 15 per target platform), assume that you decide to disribute a platform specific CAB file per product (so there would only be four CAB files per platform) plus a CAB file containing MFC8.0 DLLs per processor architecture (ARMv4 and ARMv4i).
So far, we’re talking about ten signing events per product - one executable and one CAB file per platform (PPC’02, PPC’03, WM5, PPC’03-SmartPhone, and WM5-SmartPhone) for each product, i.e. ten events per product. Four products implies forty signing events.
PPC’02 targets don’t need DLLs because the ones built into ROM are the same ones targeted by Embedded Visual Tools 3.0, but PPC’03 and WM5 targets need MFC8.0 DLLs because those platforms have MFC3.0 DLLs burned into ROM and Visual Studio 2005 builds against the MFC8.0 SDK, so every developer needs to either link statically against MFC8.0 (not such a great idea if you have more than one application dependent upon those libraries) or distribute the 8.0 DLLs with dynamically linked executables. Since PPC’03 devices are based on ARMv4 processors and WM5 devices are based on ARMv4i processors, you need one CAB file for each processor architecture. So far, we’ve generated 42 signing events to distribute four products.
Finally, assume that your licensing scheme is based on the device UUID (which can’t be ascertained over the Remote API). That means during installation you need to download a program to run a KernelIOControl routine to obtain the device UUID, potentially meaning a distinct executable per platform and a CAB file for each, so another ten signing events. So, we’re talking fifty-two signing events to distribute four products.
At $295 per GeoTrust ten pack, that imputes 6 * $295 = $1770 in annual revenue to GeoTrust to distribute four products. I don’t know about you, but I’m starting to get really pissed off.
FYI, I understand that GlobalSign has joined the Mobile2Market club by reselling GeoTrust certificates. I have yet to get a quote from them, but in general, GeoTrust seems to price themselves below GlobalSign, so I’m not particularly hopeful of getting any relief there. See: <http://www.globalsign.net/digital_certificate/objectsign/smartphone.cfm>
Mike, I wasn’t the one who priced this stuff out, but I think the first group of signing events you buy includes the usual charge for a code signing cert., i.e. you’re paying them to look you up in the yellow pages and study the faxes you send them to "prove" you’re, well, somebody. That’s about what non-mobile2market certs cost, and they’re even more if you get them from VeriSign. I think the rate I listed, which I transcribed more or less verbatim from the person here at Vertex who did the research, is for additional signing events once you’ve paid for the cert.
I believe we ended up buying a 100 pack of signing events which ran about $3 per event, and that if you bought 1000 it was more like $1 per event. But this is from memory, and I didn’t do the original research myself, so I could easily be wrong.
Unfortunately, the info isn’t posted anywhere, so you just have to call up a salesperson and pester them until they tell you what the best deal is.
It’s now $350 for getting set up (includes 10 signing events) and $12.50 per event @ 10 events down to $6.50 @ 1000 events. You can find the fees if you go through the signup process. This is difficult for smaller software companies to swallow, especially if you are trying to serve your customers by having frequent software releases. It adds up when every EXE or DLL in you CAB needs to be signed, and then the CAB itself needs to be signed, times the number of versions in each release, times the number of releases, plus the number of mistakes you make. Anyone doing freeware is going to be immediately turned off to the Windows Mobile platform as a result.
Post a Comment