For NFC payment, the app needs to access a Secure Element stored in the UICC. But we need to check a certain app has actually the right to access the UICC. Usually, the UICC has rules and knows which app it can talk to or not by checking the integrity and the identity of the app. In Firefox OS, the Access Control module doing the checks will be implemented in the OS. one way to do that isto allow an app to have two certificates: * the usual Mozilla certificate to sign the app on the marketplace * a "vendor" certificate (for NFC payment). This vendor certificate would then be checked in the FxOS system. We could think about adding a special field in the app manifest for the public key certificate.

Quick Note: Currently all NFC payment user stories are covered under: Bug 979152, Bug 979154, Bug 979157, Bug 979158, 884478. All the dependencies for those should be marked in those meta bugs.

If we can only have certified app for payment, do we still have this problem?

We're discussing about a suitable security model right now, and it will very likely not involve a vendor signature in the end. We're still working out some details, but this bug is probably going to be deprecated.

Hi Douglas, Is this something your team can help?

Hi Doug, to shed some more light on what this bug is about, have a look at this thread: https://groups.google.com/forum/#!topic/mozilla.dev.b2g/oWHfvhXAzco.

Need some folks more technical than me to recommend who needs to look at this. clouserw sicking Who needs to weigh in on this bug?

Thanks Caitlin. I would also like to mention that this is strong request from partner. We most likely need to solve it in 2.2 or sooner, so I'd prefer to kick off necessary discussions.

I think Richard Barnes and his org is the right people for the client side pieces of this. We might also need to improve the tools that we have for actually putting a signature on a package. I don't know who owns these tools. And then the marketplace needs to make sure that they don't overwrite the signature when they do their signing. They might also want to verify that the signature is correct, as well as signal a missing signature if permission to use the SecureElement-API is requested in the app manifest. These things I think fall on Wil Clouser's team.

That's correct. The Marketplace pieces were spelled out a bit in the thread linked above, but that's essentially it.

I'm honestly a little puzzled on what the use case is here. I don't see why a developer signature is different from a marketplace signature from the perspective of the access control module. The access control system trusts the marketplace to verify the developer's identity either way (either at app signing time or at developer cert issuance time). Nonetheless, if you want signatures attributable to developers, it seems like you could accommodate that within the existing code signing system -- just issue certificates to developers underneath the overall marketplace cert. If I'm missing something here, it would probably be best to have a brief call.

Hi Richard, Here is previous discussions in case you didn't get to view it yet. https://groups.google.com/forum/#!topic/mozilla.dev.b2g/oWHfvhXAzco. Hi Stephanie, Would you like to elaborate?

Hi, (In reply to Richard Barnes [:rbarnes] from comment #10) > I'm honestly a little puzzled on what the use case is here. I don't see why > a developer signature is different from a marketplace signature from the > perspective of the access control module. The access control system trusts > the marketplace to verify the developer's identity either way (either at app > signing time or at developer cert issuance time). At the moment, we need a developer signature for one main use case: NFC payment with Secure Element. The carrier we're working with has already deployed an architecture to support NFC payment on Android devices, with the Secure Element on their SIM cards. Because updating the SIM cards and pushing ACL rules is a rather unreliable process, we came to the conclusion that Firefox OS had to use the same ACL rules as on Android. These rules are the ones used by the Access Control Enforcer: - as required by the Global Platform Access Control specs, the Access Control Enforcer relies on a trusted identifier to whitelist an app (see the W3C specs draft for more details [1]). - on Android, the ACL rules on the SIM card contain the app developer's signature as an AID. Hence having to support developer signature... > > Nonetheless, if you want signatures attributable to developers, it seems > like you could accommodate that within the existing code signing system -- > just issue certificates to developers underneath the overall marketplace > cert. If I understand it right, that's proposition 3 of the first email of the deb-b2g thread [2], or do you proposed something else? https://groups.google.com/forum/#!topic/mozilla.dev.b2g/oWHfvhXAzco It looked like it was more complex to set up than proposition 1 so it was dismissed, but we can discuss it of course. [1] https://opoto.github.io/secure-element/#access-control [2] https://groups.google.com/forum/#!topic/mozilla.dev.b2g/oWHfvhXAzco

(In reply to Stephanie Ouillon [:arroway] from comment #12) > Hi, > > (In reply to Richard Barnes [:rbarnes] from comment #10) > > I'm honestly a little puzzled on what the use case is here. I don't see why > > a developer signature is different from a marketplace signature from the > > perspective of the access control module. The access control system trusts > > the marketplace to verify the developer's identity either way (either at app > > signing time or at developer cert issuance time). > > At the moment, we need a developer signature for one main use case: NFC > payment with Secure Element. > The carrier we're working with has already deployed an architecture to > support NFC payment on Android devices, with the Secure Element on their SIM > cards. Because updating the SIM cards and pushing ACL rules is a rather > unreliable process, we came to the conclusion that Firefox OS had to use the > same ACL rules as on Android. > These rules are the ones used by the Access Control Enforcer: > - as required by the Global Platform Access Control specs, the Access > Control Enforcer relies on a trusted identifier to whitelist an app (see the > W3C specs draft for more details [1]). > - on Android, the ACL rules on the SIM card contain the app developer's > signature as an AID. > > Hence having to support developer signature... Summarizing our IRC conversation, it sounds like: - ACL in the SE includes a cert for the app developer - ACE is trusted to verify that app comes from that developer So the real requirement here is for there to be a mechanism that the ACE can use to verify that the holder of the private key for the ACL cert authorizes the app trying to use the SE. > > Nonetheless, if you want signatures attributable to developers, it seems > > like you could accommodate that within the existing code signing system -- > > just issue certificates to developers underneath the overall marketplace > > cert. > > If I understand it right, that's proposition 3 of the first email of the > deb-b2g thread [2], or do you proposed something else? > https://groups.google.com/forum/#!topic/mozilla.dev.b2g/oWHfvhXAzco > It looked like it was more complex to set up than proposition 1 so it was > dismissed, but we can discuss it of course. In order to meet the above requirement, any of the three would be sufficient. I might actually prefer an even more lightweight version of (1), in which the signature with the ACL key is just another file in the app: * Developer signs with ACL key over app code, creates se-acl.sig as a file in the app * Marketplace signs over the entire app, including se-acl.sig That has the least impact on the signature process. I also have some issues with the way that the ACE architecture distributes access control responsibilities. It works OK when you have a single SE with a specific access control model that you know about at build time. It works very poorly when you take away any of those assumptions. The full discussion is for another venue, but adopting a solution here that doesn't change the app signature process helps reduce the impact of moving to a better access control model in the future. > [1] https://opoto.github.io/secure-element/#access-control > [2] https://groups.google.com/forum/#!topic/mozilla.dev.b2g/oWHfvhXAzco

Hey, I can see there's discussion ongoing, but just want to share the expected schedule plan. This is blocking Bug 884594 - Support NFC Access Control for Secure Element Access , which we committed with partner to deliver by Dec/M.

(In reply to Richard Barnes [:rbarnes] from comment #13) > > In order to meet the above requirement, any of the three would be > sufficient. I might actually prefer an even more lightweight version of > (1), in which the signature with the ACL key is just another file in the app: > > * Developer signs with ACL key over app code, creates se-acl.sig as a file > in the app > * Marketplace signs over the entire app, including se-acl.sig > > That has the least impact on the signature process. > This sounds ok. Kamil can you confirm this would be an acceptable solution? I have one question, though, about the scope we want for the developer signature support: people have expressed interest in having Firefox OS supporting developer signature for every app, so one question is: *if* this is a goal for 2.2, would that signature process be acceptable for a more general purpose than just the NFC payment case? Having the whole app signed by the developer is valuable, for example, in the case the Marketplace servers are hacked and attackers want to modify uploaded apps. 2.2 is already full with a lot of features, but we could imagine two phases: Phase 1: * support developer signature for ACE in the NFC payment case (already planned for 2.2) * adapt the Marketplace signature process (Marketplace updates happen every week, so it is less a constraint to meet the 2.2 target schedule) Phase 2: * fully support verifying the developer signature in gecko (future release) > I also have some issues with the way that the ACE architecture distributes > access control responsibilities. It works OK when you have a single SE with > a specific access control model that you know about at build time. It works > very poorly when you take away any of those assumptions. The full > discussion is for another venue, but adopting a solution here that doesn't > change the app signature process helps reduce the impact of moving to a > better access control model in the future.

Stephanie, Richard, overall solution seems good, but I'm missing one piece of puzzle here - where will the se-acl.sig file be verified? Will it be done by the Markeplace, or by the Gecko during package installation process? ps. sorry for the delayed response, I was on a leave for a couple of days.

Kamil: I'm not an expert on this system, but I would think that the Access Control Enforcer would verify this file. Stéphanie should provide the real answer.

Yeah, I would think it the ACE should verify it to make sure it hasn't been tampered with between the moment it has been installed, and the moment it is being used. But I guess we can't do this verification each time the app requests access to the SE for performance issues, so there would be some sort of cache?

So apparently we have three choices on how can we implement that: 1) In the ACE. 2) As part of the signature verification done in Webapps.jsm. 3) In the Marketplace. Ad 1. Seems to be complex, because it's quite possible we wouldn't be able to reuse the code implemented in "@mozilla.org/security/x509certdb;1". That's because, according to the comment in |nsIX509CertDB.idl|, we cannot have two certificates in one app package: > * Verifies the signature on the given JAR file to verify that it has a > * valid signature. To be considered valid, there must be exactly one > * signature on the JAR file and that signature must have signed every > * entry. Further, the signature must come from a certificate that > * is trusted for code signing. Would that mean we'd need to reimplement some of the X509 functionality in the ACE itself? Can you confirm that? Ad 2. Seems to be a better fit than having that logic in ACE, because that's the place where we could verify the signature once, upon the installation of the package, and then reuse the computed fingerprint later. But it'd still be problematic, same as in point 1 - we would need to verify two app signatures, which seems to not be supported. Ad 3. For me, it seems to be the most viable option. It could work as follows: 1) Marketplace received an app package from the developer. This package COULD contain META-INF directory if it's signed by the developer. 2) If META-INF is present, Markeplace verifies this signature. a) If signature is invalid, reject an app. b) If signature is valid, store public cert fingerprint in the manifest and continue with submisstion process. 3) User downloads an app. If either has "dev_fingerprint" key in the manifest, or not. ACE makes an decision based on that. This approach seems to be simplest of all three.

#3 seems straight forward from a marketplace POV if it does everything you want it to.

Sorry for the delay, I was on pto/sick leave. So option #3 is okay if the only goal is to identify/check who published the app. But if the signature is not checked in the ACE, then it won't be able to ensure the app hasn't been tampered with: because apps using the SE API will be privileged, an attacker could just download the app from the Marketplace, modify the code and side-load the app on the phone.

Hm, but the sideloaded app wouldn't have the valid Marketplace signature, right? When I, as a user, do such a thing - try to sideload an app to the phone with an invalid Marketplace signature (invalid, because I've modifed some files, be it .js files or manifest), will it be possible to actually sideload that app and have it installed?

Yes it is, because when an app is side-loaded, the Marketplace signature is not necessary for the app to be installed.

After a disussion with Stephanie, we think that: 1. Indeed, we cannot use the X509 facility used for the Marketplace signature verification, because it's limited to one signature per app package. See comment #19. 2. If we rely on the Markeplace to verify the signature, strip it and save only the "dev_cert_hash" in the manifest, we're exposed to a risk when user could use value of that hash, put it into the malicious app's manifest, and gain unauthorised access to the SE. 3. The SE API being privileged, if an app can be accessed via Web IDE or other debugging tool, we want to protect from spying on data exchanges. Having that in mind, the following solution seems feasible (solution #1): 1. Markeplace verifies the developer signature, and if it's correct, put's a "dev_cert_hash" into the manifest. If it's not correct, considers app package invalid and rejects it. It would also consider apps with "dev_cert_hash" to be invalid. 2. Upon package installation, Webapps.js would consider app package invalid if it contains "dev_cert_hash" in the manifest, but it's not coming from the Markeplace. 3. We would have the "non_debuggable" flag in the manifest. If present and set to true, such an app couldn't be debugged, sideloaded or accessed via Web IDE or similar tools. 4. ACE would rely on the "dev_cert_hash" from the Manifest and make an access decision based on that and the rules stored in the SIM card. So, the whole solution #1 would contain 4 parts: 1. ACE (in development now) 2. Markeplace support 3. Webapps.jsm check for the disallowed "dev_cert_hash" key 4. Support for "non_debuggable" flag Another approach (solution #2): This would involve fixing X509 implementation in Gecko. The limitation of having only one signature per package is not imposed by JAR spec, but rather it's Gecko-specific. The AppSignatureVerification.cpp which implements it (landed as part of bug 772365) intentionally does not implement support for multiple signatures. JAR spec allows that: https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html. In that scenario, we would either: - validate signature before every time access to the SE is requested. Seems like a lot of computation, though. - implement "non-debuggable" flag and prevent installation of apps with "dev_cert_hash". Then we could compute hash only once, and trust it's valid and app hasn't been tampered with. Solution #2 puts less burden on the Marketplace and seems to be more robust.

if we cannot avoid the case "side load of privileged apps without marketplace signature, but with valid dev_cert_hash", is it possible for SE/ACE to do an additional check in Gecko after the permission check? namely, to ask application manager to verify whether the calling app is signed by marketplace certificate? just like that check done during the app-installation.

(In reply to Kamil Leszczuk [:kamituel] from comment #24) > After a disussion with Stephanie, we think that: > > 1. Indeed, we cannot use the X509 facility used for the Marketplace > signature verification, because it's limited to one signature per app > package. See comment #19. > > 2. If we rely on the Markeplace to verify the signature, strip it and save > only the "dev_cert_hash" in the manifest, we're exposed to a risk when user > could use value of that hash, put it into the malicious app's manifest, and > gain unauthorised access to the SE. > > 3. The SE API being privileged, if an app can be accessed via Web IDE or > other debugging tool, we want to protect from spying on data exchanges. > > Having that in mind, the following solution seems feasible (solution #1): > > 1. Markeplace verifies the developer signature, and if it's correct, > put's a "dev_cert_hash" into the manifest. If it's not correct, > considers app package invalid and rejects it. It would also consider > apps with "dev_cert_hash" to be invalid. > > 2. Upon package installation, Webapps.js would consider app package > invalid if it contains "dev_cert_hash" in the manifest, but it's > not coming from the Markeplace. > > 3. We would have the "non_debuggable" flag in the manifest. If present > and set to true, such an app couldn't be debugged, sideloaded or > accessed via Web IDE or similar tools. > > 4. ACE would rely on the "dev_cert_hash" from the Manifest and make > an access decision based on that and the rules stored in the SIM card. > > So, the whole solution #1 would contain 4 parts: > > 1. ACE (in development now) > 2. Markeplace support > 3. Webapps.jsm check for the disallowed "dev_cert_hash" key > 4. Support for "non_debuggable" flag > > Another approach (solution #2): > > This would involve fixing X509 implementation in Gecko. The limitation > of having only one signature per package is not imposed by JAR spec, > but rather it's Gecko-specific. The AppSignatureVerification.cpp which > implements it (landed as part of bug 772365) intentionally does not > implement support for multiple signatures. JAR spec allows that: > https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html. > > In that scenario, we would either: > > - validate signature before every time access to the SE is > requested. Seems like a lot of computation, though. > > - implement "non-debuggable" flag and prevent installation of apps > with "dev_cert_hash". Then we could compute hash only once, > and trust it's valid and app hasn't been tampered with. > > Solution #2 puts less burden on the Marketplace and seems to be more > robust. I would propose we take an even lighter-weight approach. The security property we're trying to achieve here is that the ACE can verify that an app was authorized to access the SE by the holder of an authorized cert. So all that we need is for the holder of the cert to sign a statement indicating what app is authorized. * Choose an ID for the app that the marketplace guarantees to be unique * Developer creates a signature over that app ID * Would probably be good to add something here to prevent replay/re-use out of context * E.g., prepend "!MozillaAppMarketplace!" * Developer embeds signature and certificate in the app (e.g., in manifest) * Before checking SE ACL, ACE verifies: 1. App is signed by marketplace (this ensures the app ID is not spoofed) 2. Signature over app ID verifies using public key in cert * SE verifies that cert is authorized for SE access The major question here is what ID should be used. If one is already available in the marketplace, great; if not, one might have to be created. (Or it may be simpler just to sign the app, using the app itself as the unique ID.) I understand that Stéphanie is working on answering this question.

The Marketplace uses GUIDs internally. The only place they are revealed currently is download manifests, but there is no reason they couldn't be used more broadly.

This sounds good. So the developer would need to get access to this GUID to be able to sign it. If this is currenlty used internally by the Marketplace, can we imagine something like: the developer submits the app once, gets the GUID generated by the Marketplace, signs it and uploads the app again?

Overall, this seems like an acceptable solution, thanks! When thnking about that, some questions arise: 1) There is the AppSignatureVerification.cpp which does the Marketplace signature verification. It uses the C/C++ implementation of all the crypto stuff we need. Is that possible to use that logic somehow to: - validate a signature (stored in a file) of some simple string value - get the fingerprint of the certificate 2) If the developer will want to use the SE API, he/she would need to sign the known value, i.e. "!MozillaAppMarketplace!__GUID". How can this value be known before submitting an app to the Markeplace? If we're to follow the scenario just described by Stephanie (developer submits an app once, then second time with the signature of GUID), would it be possible to prevent an app from being published so it won't be visible to users until the second submission happens? For the first question, I'd like to ask you Brian for input, since you've implemented the original Marketplace verification code.

(In reply to Stephanie Ouillon [:arroway] from comment #28) > This sounds good. > So the developer would need to get access to this GUID to be able to sign > it. If this is currenlty used internally by the Marketplace, can we imagine > something like: the developer submits the app once, gets the GUID generated > by the Marketplace, signs it and uploads the app again? We can imagine it. ;) That seems like a big barrier to entry for people though and we should get UX's input on how to make it as easy as possible. Other questions include how do other stores do this, and how does this affect the built-in dev tools (they are talking about having a button in Firefox to submit your app right out of the WebIDE...not sure if they are on this bug or not).

Kamil, I think it is better to work with others on this, instead of asking me, as I don't work in this area any more.

(In reply to Kamil Leszczuk [:kamituel] from comment #29) > Overall, this seems like an acceptable solution, thanks! > > When thnking about that, some questions arise: > > 1) There is the AppSignatureVerification.cpp which does the Marketplace > signature > verification. It uses the C/C++ implementation of all the crypto stuff we > need. > Is that possible to use that logic somehow to: > - validate a signature (stored in a file) of some simple string value > - get the fingerprint of the certificate > > 2) If the developer will want to use the SE API, he/she would need to sign > the > known value, i.e. "!MozillaAppMarketplace!__GUID". How can this value be > known > before submitting an app to the Markeplace? > > If we're to follow the scenario just described by Stephanie (developer > submits > an app once, then second time with the signature of GUID), would it be > possible > to prevent an app from being published so it won't be visible to users > until > the second submission happens? > > For the first question, I'd like to ask you Brian for input, since you've > implemented > the original Marketplace verification code. Kamil/Richard, one question: will the marketplace look over and do anything with the mentioned App-ID that the developer signs over? If not, can developer create it himself?

During some discussions, an issue has been raised with the proposed approach - it'd be very hard to develop an app using SE API protected by the ACE working in the proposed way. To access a SE, developer would need to publish an app via the Marketplace and download it to his/her phone. This would needed to be done for each iteration of development/tests. The reason is that we need to prevent sideloading apps using SE (only apps with GUID coming from the Marketplace would be allowed to access SE). Without that check, someone could sideload an app and gain access to SE on an unrooted device. Is there a way we could make it easier on developers to use SE API? In the scenario #2 proposed, I think the issue wouldn't be there, because there would be no requirement for an app to be coming from the Marketplace.

So, we have several options here: 1. Providing a pref in Gecko so that one can get a custom developer build with a modified ACE which would allow developers to bypass ACE checks. -> Not ideal since the developer has to build and flash a custom build 2. Implementing the previously described scenario #2 relying on fixing X509 implementation in Gecko 3. In the Marketplace, implementing a special service for developers willing to use the SE API which would allow them to just submit the app so that it is signed for them to test it, but wouldn't expose the app to the Marketplace users. The sensitive point here is to ensure we can trust the developer, so that we don't provide a way to an attacker to bypass our security measures around SE.

(In reply to Stephanie Ouillon [:arroway] from comment #34) > > 2. Implementing the previously described scenario #2 relying on fixing X509 > implementation in Gecko > Jonas has to confirm that, but I was told that developer signature is a feature we want to have proper support for. So this solution would be the way to go...

I'm in favour of the solution no. 2 (implemeting the proper X509 in Gecko) as well. Seems like the cleanest and more robust of all the possibilities we have. Will mentioned that it's unlikely that developers would be allowed to use their own certificates, and they would be rather provided with one from the Marketplace. This is one potential point of the incompatibility, in a sense that for the SE ACE the requirement is that developer would be able to use his/her own certificate (in order for the hash to match value from the SIM card). This seems not to be a blocker, though. As a side note, please find an short howto I wrote regarding using jsrassign to verify values signed with Android keystore. Hopefully we won't need to do that, as it's a rather cumbersome and requires a lot of JS dependencies. But it works: http://kamituel.tumblr.com/post/104753711213/using-android-keystore-in-the-javascript-app-with.

(In reply to Kamil Leszczuk [:kamituel] from comment #36) > > Will mentioned that it's unlikely that developers would be allowed to use > their own certificates, and they would be rather provided with one from the > Marketplace. This is one potential point of the incompatibility, in a sense > that for the SE ACE the requirement is that developer would be able to use > his/her own certificate (in order for the hash to match value from the SIM > card). This seems not to be a blocker, though. Hum, I do see that as a blocker, since the whole point of enabling app developer signature for secure payment was to be able to re-use the same certificate. Or maybe I'm missing your point?

Having the marketplace issuing the certificate allows it to revoke them if needed. But since at this point, we're not going to rely on the developer certificate for something else than SE security, I don't think it's a strong issue right now.

Allow me to jump in and ask: It looks like we're getting close to a consensus (solution#2), which is to remove limitation of single signature per package by fixing X509 implementation in Gecko. If that is correct, how much effort needed to implement that? who can take this task? I'm asking as this seems to be the bottleneck for planned ACE in 2.2 scope.

(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #39) > Allow me to jump in and ask: > > It looks like we're getting close to a consensus (solution#2), which is to > remove limitation of single signature per package by fixing X509 > implementation in Gecko. > > If that is correct, how much effort needed to implement that? who can take > this task? > > I'm asking as this seems to be the bottleneck for planned ACE in 2.2 scope. Kamil is responsible for ACE in Gecko. The estimated effort for implementing solution#2 in Gecko would be 1~2 weeks. After that, we need to integrate it back to the overall SE stack, and do the developer & QA testing and so on. Is it possible to reach a consensus for this issue before Christmas?

I have scheduled a catch-up with Kamil & Ming Yin tomorrow to talk through the signature decision but I also wanted to explain the new debugging security model since I think its not well known or documented yet: - Firstly there is now a very simple solution to side-loading. We now have a blacklist of permissions that are not allowed to be sideloaded (see bug 1064108 for details) on production phones. We just need to add the secure-element permission to this list. In 2.1 and beyond ONLY sideloaded apps can be debugged (with web IDE etc), so this means that for production devices (unrooted) that no apps with secure-element can be sideloaded, and also that no apps from installed from marketplace (possibly with secure-element) can be debugged on production devices. - For developers, they will need the ability to sideload. There is a preference [1] that can be changed on a rooted device so that the above sideloading check is removed. With this preference changed, developers can just sideload their app with any permissions. The can also debug any app they want and also debug gecko javascript code (which is effectively root access). - Previously a developer needed root to change this preference on a production device. However to encourage development, very soon we will add an option to the developer menu to allow this (bug 1100964). IE by default, Firefox OS users will be convert their production phones into a developer phone and at this point the device is effectively rooted. So if we wanted to go with Richards proposal in comment 26, I think we could just by disabling the ACE when developer mode is enabled. Hopefully that clears things up from a debugging perspective, and we can discuss the merits of both signing proposals tomorrow. I've heard general support from Jonas on getting developer signatures (it would also be useful for things like developer reputation systems) but I also want to make sure we don't go through the risk and effort of redoing our signing/verification code just to support once use case. [1] devtools.debugger.forbid-certified-apps

Hi Paul, so do we have some final decision, which solution we want to implement?

(In reply to Kamil Leszczuk [:kamituel] from comment #42) > Hi Paul, so do we have some final decision, which solution we want to > implement? I spoke with Jonas and Richard via email, sorry was travelling so didn't get to send you a response. The summary was basically that multiple signature support raises a lot of other questions that we don't have the answers for yet, and also the developer signing support Jonas was interested in is something separate from multiple signatures. So based on that I think we should try to find the solution with the least risk/impact, which I think is one based on Richard's proposal in comment 26. (IE the sign-the-app-id solution)

Can I also summarise the outcome of our discussion earlier in the week, just to make sure everyone is on the same page. Please correct me if wrong. My understanding was: 1. Developer signs an app ID (from marketplace) with their signature 2. ACE will: CHECK 1: the signature over app ID verifies using public key in cert CHECK 2: the developer cert is authorised for SE access The open question is, how can we allow developers to sideload SE apps but make it so that only authorized apps have access to the SE card. My answer to this was to have a preference which prevents side loading SE apps, and require developers to use rooted devices. The logic being, if the device is rooted, then gecko can't protect SE anyways since root permissions allow complete access. So we could just disable ACE but Kamil expressed a preference to still check the developer certificate, but not the signature over the appid when the device was in developer mode. Thats obviously not a strong check, but maybe it means at least the app must contain the certificate when testing to make it easier for developers when they submit to marketplace. Am I on the right track?

I just want to clarify that "App Id" here doesn't mean what we internally in Gecko refer to as "App Id", right? Internally in gecko we have a concept of "App Id" which is a 32-bit integer value which identifies the app. This App Id is entirely specific to the device and used as an internal performance optimization. Since that App Id is device-specific, it can't be meaningfully signed. So I'm guessing the "App Id" that you are talking about is something else?

(In reply to Jonas Sicking (:sicking) from comment #45) > I just want to clarify that "App Id" here doesn't mean what we internally in > Gecko refer to as "App Id", right? Internally in gecko we have a concept of > "App Id" which is a 32-bit integer value which identifies the app. > > This App Id is entirely specific to the device and used as an internal > performance optimization. > > Since that App Id is device-specific, it can't be meaningfully signed. > > > So I'm guessing the "App Id" that you are talking about is something else? My understanding is that it is the GUID from comment 27. We'd need to reveal that in an API or upon install or something.

(In reply to Wil Clouser [:clouserw] from comment #46) > (In reply to Jonas Sicking (:sicking) from comment #45) > > I just want to clarify that "App Id" here doesn't mean what we internally in > > Gecko refer to as "App Id", right? Internally in gecko we have a concept of > > "App Id" which is a 32-bit integer value which identifies the app. > > > > This App Id is entirely specific to the device and used as an internal > > performance optimization. > > > > Since that App Id is device-specific, it can't be meaningfully signed. > > > > > > So I'm guessing the "App Id" that you are talking about is something else? > > My understanding is that it is the GUID from comment 27. We'd need to > reveal that in an API or upon install or something. Hi Will, Regarding this GUID exposure, I suppose someone from marketplace team can take. Do you know who and ETA? You might want to create a separate bug. For FxOS v2.2, feature landing date will be Feb23 but we intend to land features two weeks earlier (which is Feb13.) Cheers, Wesley

I'm happy to file another bug, but want to make sure it is what you want. Would just adding it to the output of the app detail page on our API[1] be good enough (it would mean another HTTP request?) or do you want it in the install() call or something? [1] For example, the API drawing https://marketplace.firefox.com/app/twitter is at https://marketplace.firefox.com/api/v2/fireplace/app/twitter/?cache=1&lang=en-US&limit=25&region=us&vary=0

(In reply to Wil Clouser [:clouserw] from comment #48) > I'm happy to file another bug, but want to make sure it is what you want. > Would just adding it to the output of the app detail page on our API[1] be > good enough (it would mean another HTTP request?) or do you want it in the > install() call or something? > > [1] For example, the API drawing https://marketplace.firefox.com/app/twitter > is at > https://marketplace.firefox.com/api/v2/fireplace/app/twitter/ > ?cache=1&lang=en-US&limit=25&region=us&vary=0 It is enough to just adding it to the output of the app detail page. The end2end story looks as follows. (hopefully, it reflected correctly our discussions/proposals so far.) A. SE-App Development 1. Developer implements the app with SE permission ("secureelement-manage") 2. Developer certificate needs to be present in the app (public certificate in manifest) 3. While in debug mode ACE will compare certificate fingerprint with value on SIM card B. Marketplace publication 1. During the marketplace submission process user is presented with GUID value 2. Developer creates signature over GUID 3. Developer embeds signature, GUID and certificate in the app 4. Developer publishes the final app version to marketplace. (update app) C. App installation and usage of SE-API 1. User installs the app from marketplace. Regular marketplace certificate check is being performed 2. App accesses SE. Additional, verification done by ACE: 2.1. Verifies if app is signed by marketplace (to check app integrity) 2.2. Verifies signature over GUID 2.3. compare certificate fingerprint with the value retrieved from SIM card More info including the planed engineering tasks can be found at https://docs.google.com/document/d/1EuTFSefQRFTDxF1U2CYvo2IP0jVFl18AsYCdMRu_9hg/edit

Paul/Richard/Stephanie, what's your feedback on comment-49? can we break down the solution into engineering tasks now?

(In reply to Ming Yin from comment #49) > (In reply to Wil Clouser [:clouserw] from comment #48) > > I'm happy to file another bug, but want to make sure it is what you want. > > Would just adding it to the output of the app detail page on our API[1] be > > good enough (it would mean another HTTP request?) or do you want it in the > > install() call or something? > > > > [1] For example, the API drawing https://marketplace.firefox.com/app/twitter > > is at > > https://marketplace.firefox.com/api/v2/fireplace/app/twitter/ > > ?cache=1&lang=en-US&limit=25&region=us&vary=0 > > It is enough to just adding it to the output of the app detail page. > > The end2end story looks as follows. (hopefully, it reflected correctly our > discussions/proposals so far.) > > A. SE-App Development > 1. Developer implements the app with SE permission ("secureelement-manage") > 2. Developer certificate needs to be present in the app (public certificate > in manifest) > 3. While in debug mode ACE will compare certificate fingerprint with value > on SIM card > > B. Marketplace publication > 1. During the marketplace submission process user is presented with GUID > value > 2. Developer creates signature over GUID > 3. Developer embeds signature, GUID and certificate in the app > 4. Developer publishes the final app version to marketplace. (update app) > > C. App installation and usage of SE-API > 1. User installs the app from marketplace. Regular marketplace certificate > check is being performed > 2. App accesses SE. Additional, verification done by ACE: > 2.1. Verifies if app is signed by marketplace (to check app integrity) > 2.2. Verifies signature over GUID > 2.3. compare certificate fingerprint with the value retrieved from SIM card > > More info including the planed engineering tasks can be found at > https://docs.google.com/document/d/ > 1EuTFSefQRFTDxF1U2CYvo2IP0jVFl18AsYCdMRu_9hg/edit Hi Wil, please let me whether it is OK for you.

Thanks, Ming. The summary makes it very clear. I suggest the Marketplace adds an immutable field named GUID to the "Technical Details" of the app detail pages, accessible only by the app authors. I'm attaching a quick mock-up. If you agree I'll file a separate bug.

(In reply to Wil Clouser [:clouserw] from comment #52) > Created attachment 8546214 [details] > guid.png > > Thanks, Ming. The summary makes it very clear. I suggest the Marketplace > adds an immutable field named GUID to the "Technical Details" of the app > detail pages, accessible only by the app authors. I'm attaching a quick > mock-up. If you agree I'll file a separate bug. Hi Wil, I am OK with it. Many thanks for your quick response!

Hi Ming, it looks good, adding some comments on the google doc.

Hi Ming, Just checked the google doc and I have two quick questions: 1. Is there remaining effort needed from Gecko side, or just the operation? 2. As the conclusion gets clear, can either you or Kamil take this bug? (Assignee field)

(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #55) > Hi Ming, > Just checked the google doc and I have two quick questions: > 1. Is there remaining effort needed from Gecko side, or just the operation? > 2. As the conclusion gets clear, can either you or Kamil take this bug? > (Assignee field) we don't need any additional effort on Gecko side. Please assign this bug to Kamil. thanks.

OK. So this bug now is more for discussion and operation? I'm setting target milestone to Feb6 as a checkpoint. By that time let's see if we can close the bug.

what are the next steps here?

Hi Doug, based on the agreed concept in this bug, we are implementing it for ACE (in parent process). Next steps as engineering tasks are as follows: 1) to have window.crypto in parent (DONE); 2) to verify the signature using public key from developer certificate; 3) to compute certificate fingerprint (SHA1) of the developer certificate and compare it with Access rules retrieved from sim card The detailed implementation plan for ACE including developer signature support is defined in document https://docs.google.com/document/d/1EuTFSefQRFTDxF1U2CYvo2IP0jVFl18AsYCdMRu_9hg/edit

removing flags as actual "code landings" will be on ACE (bug 884594)

Any updates? manifest.etag seems to be a stable, signable value between marketplace app installations on a device. There's also the suggestion of creating yet another ID field that can be filled in for signing purposes.

I think we should stick to the GUID, since it's already exposed to the developer in the marketplace. The question is how we can get the original GUID value for verification on the device. Right now I'm testing with apps pushed via WebIDE, so I'm just adding it myself to the manifest file. Wil, is GUI available on the device and can be added to manifest.file?

(In reply to Krzysztof Mioduszewski[:tauzen] from comment #62) > I think we should stick to the GUID, since it's already exposed to the > developer in the marketplace. The question is how we can get the original > GUID value for verification on the device. Right now I'm testing with apps > pushed via WebIDE, so I'm just adding it myself to the manifest file. > > Wil, is GUI available on the device and can be added to manifest.file? The GUID is in the URL when the device installs the app. Past that I don't know if the device stores it somewhere. I doubt the device can modify the manifest though, since all of that is signed and the marketplace doesn't modify manifests either. The steps above said showing the GUID in the dev tools was enough and the developer would manually add it.

(In reply to Wil Clouser [:clouserw] from comment #63) > The steps above said showing the GUID in the dev > tools was enough and the developer would manually add it. OK, you're right, developer needs to add the GUID to manifest (comment 49 step B.3). In step C.2.2 comment 49 we need to verify the signature over GUID. We need to be sure that GUID in manifest file comes from the Marketplace and is valid (belongs to this particular app). I think, that while re-uploading the app with GUID, signature and cert, Marketplace should check if the GUID added by the developer in the manifest matches the one in Marketplace (and block upload if it does not match). I don't see this check mentioned in the above comments. Is this implemented in Marketplace? If not, I think it should be added.

Yes. Can you file another bug with specifics about what you're looking for (the name of the field, and where it is in the manifest), what you want us to do (reject, I guess?), and the wording of the error messages. Thanks.

Firefox OS is not being worked on