Symbiansigned & Verisign concerns

"Lucas Maneos" <[email protected]> schreef in bericht
news:krmaTDBtFHA.772@extapps30...
> Hello,
>
> we are currently developing our first Symbian OS application, and we
> started looking into the symbiansigned program. We are still debating
> whether it's worthwhile getting involved in this process, but the
> information we have seen so far raises a few points of concern:
>
> 1. We are confused in regards to what a Verisign signing certificate
> actually buys us.
>
> The symbiansigned website (<https://www.symbiansigned.com/app/page/faq>😉
> states the following:
>[color=green]
>> Q. How much does it cost to get an application signed?
>>
>> A. You will need to buy an ACS Publisher ID from VeriSign (which costs
>> $350). This will identify you as the source of an application and you
>> will need this to sign any applications that you submit for testing. This
>> allows the Test House to verify the application is (a) from you, and (b)
>> has not been tampered with before it reaches them. Your own ACS Publisher
>> ID can be used to sign an unlimited number of applications, though you
>> will need to renew it on annual basis.
>
> However the Verisign website
> (<http://www.verisign.com/products-services/security-services/code-signing/symbian-content-signing/index.html>😉
> paints a different story:
>
>> # Starter pack includes a ACS Publisher ID digital certificate, and 10
>> free ACS Content IDs (signing events).
>>
>> # You can purchase additional ACS Content IDs (signing events) after you
>> get your ACS Publisher ID.
>>
>> # One (1) ACS Content ID signing event digitally signs one file.
>>
>> # Your ACS Publisher ID and any unused ACS Content IDs (signing events)
>> expire one year from the date of ID issuance. You will be sent a renewal
>> notice for your ACS Publisher ID in advance.
>
> Note the discrepancy between "can be used to sign an unlimited number of
> applications" and Verisign's "10 signing events". Could this be
> clarified please?
>
>
> 2. We are also concerned about which certificate it is that actually
> signs the binary that is released to end-users. If I understand the
> following correctly:
>
> <https://www.symbiansigned.com/app/page/process>:
>
>> 12. Once all the tests have been passed, the application is re-signed
>> using a single use ACS Publisher ID that is trusted through the Symbian
>> Root Certificate embedded on the phones. This end certificate
>> contains the original developer information for complete traceability to
>> the originator.
>
> <https://www.symbiansigned.com/how_do_I_get_my_application_signed.pdf>:
>
>> Once your application has successfully passed all of the tests conducted
>> by the Test House, the Test House will upload your application to
>> VeriSign, the Certificate Authority. VeriSign will remove the ACS
>> Publisher ID, store details of the application in a revocation database1,
>> resign the application against the Symbian root
>> certificate, and send the signed application back to the Test House.
>> The Test House will inform you that you are able to download your Symbian
>> Signed application from the site.
>
> the developer's signature is thrown away during the process, and the
> binary is signed by Verisign using Symbian's root certificate.
>
> Doesn't this mean that a malicious Verisign employee would be able to
> sign any binary so that it appears to a) be blessed by Symbian and b)
> come from any developer they chose?[/color]

Yes. As soon as a "Trusted" party cannot be trusted, you have no guarantuees
at all. Similar, the Testing house must also "trusted" in the sense that
they will not create bogus testing reports.

> Several concerns here:
>
> a. Symbian trusts Verisign with their root key and allows them to sign
> things in their name.

I don't think that's correct. Verisign is the party that tells other parties
that developer A is indeed Developer A, located at whereever and who has
coughed up USD 350.

> b. Developers (or anyone, really) could be implicated in malicious code
> since they have no control over what could be signed in their name.

I don't think so. The sis file is signed by Developer A and by the Testing
house. The Testing house signs the signed sis file of Developer A.
The signing by Developer A tells the world that the sis file has been signed
by an entity X in possession of *the* Verisign ACS, that has been issued by
Verisign to Developer A. As long as Developer A is the only entity in th
world using that ACS, X must be Developer A.
The signing by the testing house is what makes the sis file Symbian Signed.
This tells the world that a program is likely to behave as it should and (in
Symbian OS 9.1 and higher) is not doing malicious things secretly.

> c. End users can not really be sure where a signed binary really
> originates from.

There are a number of points where the system can go wrong

a) Developer A's ACS is stolen and Virus writer B is using it to create a
program that acts maliciously.

While not impossible, such a scam is so hard to pull off that I cannot
imagine a private party doing this. The reason is of course that party B
must pretend to be A to the Testing house for the lenght oif the test. For
instance, B must receive at least one invoice and pay it. I don't see some
teenage kid behind his computer pulling this trick

b) Verisign is corrupt.

Virus Writer B acting as Developer A still has the problem of fooling the
Testing House. Virus Writer B posing as Developer B can pull the stunt. But
in this case ther must be a developer B. If there is no such entity,
Verisign is immediately implicated.

c) the Testing house is corrupt.

Who cares. They cannot create programs, unless they are also developers. Or,
they are developers acting as their own testing house. In both cases you
know their identity, unless Verisign is also corrupt.

d) They are all corrupt.

Then you loose. But since the cost of such an operation is large, there are
few entities willing and capable of doing it. A big criminal organisation,
or any government with good ties with the USA (because of Verisign) could do
it.

> 3. We are also wondering why Symbian has apparently granted Verisign a
> monopoly in this market. This is certainly not to the developers'
> benefit given that code signing certificates are available elsewhere
> under much more reasonable prices and terms.

The phone manufacturers and operators must also endorse the certificate
issuing party. Operators especially are quite paranoid.

> Examples:
>
> - ComodoGroup
> (<http://www.instantssl.com/code-signing/code-signing.html>😉 offer code
> signing certificates for GBP 66.00 per annum.
>
> - Cybertrust
> (<http://www.globalsign.net/digital_certificate/objectsign/index.cfm>😉
> EUR 175.00 per annum.
>
> Both are well known CAs whose root certificates are present in all
> modern web browsers. None of them have "signing event" charges.
>
> Cybertrust also offers code signing certificates to private individuals
> which would be of benefit to smaller (non-incorporated) developers who
> are currently excluded from symbian signed.
>
> BTW, Verisign's USD 350.00 introductory offer (which the
> symbiansigned.com website repeatedly refers to) expired over two months
> ago.
>
> If there isn't a valid technical reason for symbiansigned certs to only be
> available from one source, can we expect more reasonable alternatives
> soon?

--
Sander van der Wal
www.mBrainSoftware.com

>Note the discrepancy between "can be used to sign an unlimited number of
>applications" and Verisign's "10 signing events". Could this be
>clarified please?

The VeriSign ACS Publisher ID is what you need for Symbian Signed. This is a
unique ID issued to you, once VeriSign have verified you are who you say you
are, etc. This is the first key feature of Symbian Signed - traceability. The
ACS Publisher ID is an industry-standard concept and as such is usable in
different contexts. When VeriSign refer to the 10 instances included in the
price, these are actually not used in the Symbian Signed process...but should
you be a cross-platform developer and work with another testing and
certification program which uses the ACS *and* these instances, then they would
be of use to you. For Symbian Signed's purposes, this can be ignored...

Once you have your ACS ID, it can indeed be used to sign an unlimited number of
SIS files as the first stage through the Symbian Signed process.

>2. We are also concerned about which certificate it is that actually
>signs the binary that is released to end-users. If I understand the
>following correctly:

In short, the process is as follows:

1) Get your ACS ID - proves you are who you say you are
2) Sign your own SIS file with your ACS ID
3) Submit to Test House
- Test House checks ACS ID details
- This lets them verify (a) the SIS has not been tampered with en-route,
(b) that the SIS has indeed come from the source it claims to have
4) However, as I mention, the ACS ID is an industry standard concept. There is
nothing inherently Symbian Signed specific about this. Anyone with an ACS ID can
sign a SIS file but there is no guarantee therefore that it has been through
(and passed) the Symbian Signed test criteria
5) So, if your application passes the tests, what actually then happens is the
SIS file is re-signed against a new certificate which chains back to a root
certificate entirely owned and controlled by Symbian. This root is ONLY used in
Symbian Signed and the only way to be signed by it, is to pass the process. This
control enables us to guarantee that any SIS file Signed against this
certificate has been through the process
6) You receive your SIS back to distribute. At install time, the installer is
able to perform similar checks to (3) - i.e. that no tampering has taken place
and that the SIS signature properly chains back to the Symbian Signed root
(technical detail: this root we refer to as "Symbian.B" in case you hear that).

In short, yes, the SIS file is signed twice...but with two different purposes in
mind. Both convey trust and traceability, but in a different way.

>Doesn't this mean that a malicious Verisign employee would be able to
>sign any binary so that it appears to a) be blessed by Symbian and b)
>come from any developer they chose?

VeriSign is a trusted organisation - to be honest, any "malicious employee"
activity would have far bigger consequences than one incorrectly signed Symbian
Signed SIS file. One would expect VeriSign to have industrial-strength
counter-measures in place for such a core part of their business!

>3. We are also wondering why Symbian has apparently granted Verisign a
>monopoly in this market. This is certainly not to the developers'
>benefit given that code signing certificates are available elsewhere
>under much more reasonable prices and terms.

Symbian Signed is an evolving program which has so far worked extremely well -
it has been endorsed as a model setup by the GSM Association, has received wide
backing from the mobile industry (e.g. phone manufacturers, network operators)
and has already delivered cost reductions of over 75% since launch to its users.
We have achieved this by doing a gradual, considered evolution. Launching the
program and getting the fundamentals correct, working and approved was the
essential first step. As with any large project where you do not have unlimited
resources, this required a focused approach and working with a few key partners.
Now that Symbian Signed is launched and is working very well, the next stage in
its evolution is expanding this range of partners to deliver improved service
and increased competition (just as we did with Test Houses to reduce costs so
much - we launched with one partner and have now brought on board two more). I
can assure you were are working behind the scenes with other signing and
verification providers.

Regards,

Phil

Phil Spencer wrote:
> When VeriSign refer to the 10 instances included in the
> price, these are actually not used in the Symbian Signed process...but should
> you be a cross-platform developer and work with another testing and
> certification program which uses the ACS *and* these instances, then they would
> be of use to you. For Symbian Signed's purposes, this can be ignored...

Thanks for clarifying this. Confusingly, the Verisign page gives the
appearance of being specific to the Symbian Signed product, perhaps this
could be made explicit in the FAQ?

> 5) So, if your application passes the tests, what actually then happens is the
> SIS file is re-signed against a new certificate which chains back to a root
> certificate entirely owned and controlled by Symbian.

The PDF document I referenced before claims that it is Verisign who does
the actual signing against the Symbian root. Which entity is in
possession of the Symbian root key, Symbian or Verisign (or both)?

> In short, yes, the SIS file is signed twice...but with two different purposes in
> mind. Both convey trust and traceability, but in a different way.

Can you confirm, one way or the other, whether the original signature
(using the developer's ACS ID) remains in the final distributable SIS
file? All the documentation I've seen so far indicates that it gets
removed at the test house stage and/or by Verisign.

Also, if the developer signature does remain in the binary, can it be
used to prove or disprove the origin of a particular binary a) in a
court of law and b) to the general public (eg, if we publish our ACS
public key on our website, is there a way for an end user to verify
whether the ACS signature on a SIS file matches?)

Note that I'm not talking about the ACS signature being accepted for
installation/execution purposes here, just the traceability/repudiation
aspects of it.

> VeriSign is a trusted organisation - to be honest, any "malicious employee"
> activity would have far bigger consequences than one incorrectly signed Symbian
> Signed SIS file. One would expect VeriSign to have industrial-strength
> counter-measures in place for such a core part of their business!

One would, yes. A malicious employee is just one of the many things
that can go wrong, and Verisign have been known to screw up before
(<http://www.cert.org/advisories/CA-2001-04.html> is one example we've
all heard about).

> Symbian Signed is an evolving program which has so far worked extremely well -
> it has been endorsed as a model setup by the GSM Association, has received wide
> backing from the mobile industry (e.g. phone manufacturers, network operators)
> and has already delivered cost reductions of over 75% since launch to its users.

I appreciate that, but I must submit to you that for a new entrant to
the market the costs are still quite high.

Using the cheapest test house alternative for just a beta release, a 1.0
release and a couple of bug fixes the signing costs are (USD 400.00 + 4
x EUR 185.00) USD 1309.14 using today's xe.com exchange rates, payable
up-front.

Given the average price for a symbian app and the extortionate rates
that distributors are charging this translates to over 100 sales just to
recoup the signing overheads for what is, essentially, a single revenue
stream.

(In the calculations above I'm assuming that all tests are passed first
time, which might not be realistic. Are there any success/failure rate
statistics available?)

One more question: The Symbian Signed legal agreement contains the
following clause:

> 6.5. Following Testing of your Application, the Testing House may
> provide you with a Test Report. You agree to keep the details of the
> Test Report confidential and not to disclose it to third parties.

What is the rationale behind this?

Thanks,
Lucas

Hi Lucas,

>Thanks for clarifying this. Confusingly, the VeriSign page gives the
>appearance of being specific to the Symbian Signed product, perhaps this
>could be made explicit in the FAQ?

Yes, we agree this is a bit confusing - we will be chasing up VeriSign to change
this and make it clearer.

Incidentally, going back to how the process works, there is some additional
information which I omitted in my first reply which you may want just for
completeness. Regarding the 'two signings', I described the process in detail
but just for clarity, the ACS you purchase from VeriSign to uniquely identify
you, roots to a VeriSign Class 3 CA root owned by them. The 'Content ID' which
the SIS file is re-signed with roots to something we call "Symbian.B" owned by
us which is ONLY used in the Symbian Signed process. The following information
is based on an FAQ from VeriSign ("Why do I need to get 2 different
certificates?"😉 which I have edited slightly for some extra clarity in view of
the Symbian Signed process specifically:

"The ACS Publisher ID is essentially a developer authentication certificate. You
sign your code with your ACS Publisher ID to prove its origin in the first
instance. After successful testing, your original code which has been signed
with your ACS is then passed on to VeriSign for "re-signing". As part of this
re-signing process, a new unique Content ID Certificate is generated by
VeriSign. When code signed with your ACS is uploaded to VeriSign, we check the
validity of the signature in real time, strip off this signature and re-sign
using a Content ID certificate that (a) carries application specific information
(b) chains up to the private root CA associated with the platform or carrier you
are signing your applications for. The Content ID is unique to each piece of
content and is the only signature that will be trusted on the end-user device
for secure downloading and execution."

>The PDF document I referenced before claims that it is VeriSign who does
>the actual signing against the Symbian root. Which entity is in
>possession of the Symbian root key, Symbian or VeriSign (or both)?

Symbian owns the Symbian.B root. However, for the purposes of this process
VeriSign are in possession of it in order to be able to sign SIS files which we
request they sign (i.e. ones which have passed the testing process) on our
behalf. This is a normal and accepted, best-practice process in terms of PKI
(Public Key Infrastructure) standards. Roots *must* be secured otherwise the
whole PKI process will fail. Physical and practical protection details are of
course left up to the CA - but it is the norm to see 'Fort Knox' style security
employed to protect such roots!

Again for completeness...for Symbian OS v9 onwards there is an additional root
called Symbian.A which is used exclusively for the creation of Developer
Certificates (see www.symbiansigned.com for more details) which we also own. We
are the only people who use and sign with this root. Incidentally, please do not
ask why Symbian.A is for DevCerts and Symbian.B is for Symbian Signed when it
was Symbian Signed which came first, because I do not know 😊

>Can you confirm, one way or the other, whether the original signature
>(using the developer's ACS ID) remains in the final distributable SIS
>file? All the documentation I've seen so far indicates that it gets
>removed at the test house stage and/or by VeriSign.

In my desire to give a quick explanation before I perhaps used slightly
confusing terminology, so my apologies for that. The SIS file doesn't really get
'signed' twice as such. What VeriSign do is *re-sign* the original SIS file you
submit to the process (see the FAQ text above). Vital information pertaining to
the ISV is preserved from the SIS originally signed with the ACS ID - so for
example when you install a Symbian Signed application, you see the ISV's ACS
details on the information dialog. (Again for completeness, in Symbian OS v9,
Test Houses will temporarily unsign a local copy of your SIS file once it has
been verified as not having been tampered with and originating from the ACS ID
owner. They will then sign that 'naked' SIS file with their own DevCert to allow
complete testing on their hardware and then - if the tests are passed - they
will submit the ORIGINAL SIS signed with your ACS ID through to be re-signed by
VeriSign as now).

>Also, if the developer signature does remain in the binary, can it be
>used to prove or disprove the origin of a particular binary a) in a
>court of law and b) to the general public (eg, if we publish our ACS
>public key on our website, is there a way for an end user to verify
>whether the ACS signature on a SIS file matches?)
>
>Note that I'm not talking about the ACS signature being accepted for
>installation/execution purposes here, just the traceability/repudiation
>aspects of it.

Yes, all Symbian Signed SIS files are traceable to the original ACS -
effectively via the unique Content ID which is generated during re-signing. I
would not feel comfortable making any statements about what may or may not be
provable in a court of law in any given jurisdiction, to any given burden of
proof - this would really be a matter for any court in question to determine.

>I appreciate that, but I must submit to you that for a new entrant to
>the market the costs are still quite high.
>
>Using the cheapest test house alternative for just a beta release, a 1.0
>release and a couple of bug fixes the signing costs are (USD 400.00 + 4
>x EUR 185.00) USD 1309.14 using today's xe.com exchange rates, payable
>up-front.

We are doing all we can to continue to reduce costs - and as I said, I am
personally very proud to have been involved with Symbian Signed since its launch
and see reductions of over 75% already (as the entire team are). In your
specific example, I am not sure why you would currently sign a beta release -
Symbian Signed by its nature is meant to be for finished products which have
already been thoroughly tested and are ready to go to market. From Symbian OS v9
onwards this may be a consideration (depending on how wide and/or tech-savvy
your beta testing group is, i.e. whether it is feasible to request they use
DevCerts for their own phones) though, I agree. But then we are continuing to
try and bring down costs as I have said.

One other point - for repeat test runs/re-tests, the Test Houses very often
offer reduced rates so it is perhaps overly-simplistic to take 185 Euro as the
cost for all runs. Again, this is an example of the Test Houses and market
responding to the real world scenarios as the process evolves.

We are always interested to hear suggestions for improvements or ways of
reducing costs, overhead or complexity - if you have any suggestions, I would be
very happy to take them and examine them with the rest of the Symbian Signed
team.

>(In the calculations above I'm assuming that all tests are passed first
>time, which might not be realistic. Are there any success/failure rate
>statistics available?)

We do not publish any current accurate success/failure rates. I do know that
since launch (when they were only around 50%) first-pass rates have improved
significantly as we have ourselves improved the supporting documentation, tools
and indeed the test criteria itself (especially with regard to valid exceptions
which have arisen as a direct result of developer feedback on real world
scenarios). As I said in my first reply, Symbian Signed is an evolving program -
we can only make it better as we get more valuable feedback.

>One more question: The Symbian Signed legal agreement contains the
>following clause:
>[color=green]
>> 6.5. Following Testing of your Application, the Testing House may
>> provide you with a Test Report. You agree to keep the details of the
>> Test Report confidential and not to disclose it to third parties.
>
>What is the rationale behind this?[/color]

Good question! I have checked in to this and (as is often the case with legal
agreements!) it arose as a basic protection for Test Houses regarding what
comments they may sometimes make on products under test. Sometimes, for example,
a Test House (especially one familiar with a particular ISV) may put informal
comments like 'nice application, well executed' on their test results. In these
cases, they would like to have some discretion as to whether these comments were
taken and used as public endorsements, for example. The simple approach this
encourages is to be pragmatic and ask the Test House if they are happy for you
to disclose use the contents of their test feedback before doing so. I am sure
in many cases they would be OK with this if it was a reasonable request.

If people feel strongly that this is an inappropriate approach and clause, I'd
urge them to post feedback here to let us know. This is (AFAIK) the first time
this has been raised, but we are happy to look at reviewing things which people
feel are 'showstopper' problems with the licence.

I hope these further answers help you - please do let me know if you have any
more questions.

Kind regards,

Phil

Hi Phil,

> "The ACS Publisher ID is essentially a developer authentication certificate. You
> sign your code with your ACS Publisher ID to prove its origin in the first
> instance. After successful testing, your original code which has been signed
> with your ACS is then passed on to VeriSign for "re-signing". As part of this
> re-signing process, a new unique Content ID Certificate is generated by
> VeriSign. When code signed with your ACS is uploaded to VeriSign, we check the
> validity of the signature in real time, strip off this signature and re-sign
> using a Content ID certificate that (a) carries application specific information
> (b) chains up to the private root CA associated with the platform or carrier you
> are signing your applications for. The Content ID is unique to each piece of
> content and is the only signature that will be trusted on the end-user device
> for secure downloading and execution."

Thanks, that's clear now.

> We are always interested to hear suggestions for improvements or ways of
> reducing costs, overhead or complexity - if you have any suggestions, I would be
> very happy to take them and examine them with the rest of the Symbian Signed
> team.

Well, more flexible and reasonably-priced CAs (like the couple I
mentioned earlier) would be nice 😊

> it arose as a basic protection for Test Houses regarding what
> comments they may sometimes make on products under test. Sometimes, for example,
> a Test House (especially one familiar with a particular ISV) may put informal
> comments like 'nice application, well executed' on their test results. In these
> cases, they would like to have some discretion as to whether these comments were
> taken and used as public endorsements, for example. The simple approach this
> encourages is to be pragmatic and ask the Test House if they are happy for you
> to disclose use the contents of their test feedback before doing so. I am sure
> in many cases they would be OK with this if it was a reasonable request.
>
> If people feel strongly that this is an inappropriate approach and clause, I'd
> urge them to post feedback here to let us know.

I was thinking more about the case of negative test results actually.
In other words, if my app failed a test I feel I should be able to
discuss it (here and/or in other fora) to get advice on how to fix it,
without having to obtain written permission from the test house first.

Thanks,
Lucas