Dear All,
This is the additional analysis result, we’ve done regarding the signature subject Widget signature features refers to (at least) following specifications: http://www.w3.org/TR/widgets-digsig/ http://www.w3.org/TR/xmldsig-core1/ http://www.w3.org/TR/xmldsig-properties/ In original WRT, implementation of widget digital signature was based on *vcore* component of *cert-svc* repository. This code was heavily aimed on WRT implementation. The only role of WRT was to collect signature files from widget directory. Cert-svc API was able to validate widget signature and calculate privilege level (public, partner, platform). Cert-svc used internally *libxml and libxmlsec1* to validate widget signature. In current crosswalk implementation, there is no cert-svc layer. Considering: WRT --> cert-svc --> libxmlsec1 --> libxml/other stuff 'cert-svc' layer was reimplemented inside crosswalk. The implementation seems to be more or less complete. Signatures validation assumes X509 certificates being used in signature and there is no handling for other way of signing the widget as previously. The difference is that privilege level calculation is not done in crosswalk. Easiest option seems to be porting this implementation to app-installers and just fixing missing items. Finally, in case of *key-manager*, I don't know what role can be played by key-manager in such approach. It seems to be counterpart for libxmlsec1 but only in term of certificate validation (xmlsec1 internals). In that scenario, all xmldsig implementation needs to be provided as well which certainly is not key-manager role. In the attachment, you can find details about the requirements vs implementation in WRT vs crosswalk vs app-installers. Best Regards, Pawel Sikorski From: Dev [mailto:[email protected]] On Behalf Of Pawel Sikorski Sent: Tuesday, November 25, 2014 11:01 AM To: 'Baptiste Durand' Cc: [email protected] Subject: Re: [Dev] App Installer WorkShop Status Hi Baptiste, Yes, it should be independent. It is the intention here. I just meant to reuse part of the code, and just clean dependent parts. As for the Encryption, what I understood, firstly we are focusing on steps mentioned in https://bugs.tizen.org/jira/browse/TC-2061 (sub tasks). But yes, it is a good plan, to start to separate “encryption” feature. I will ask someone to take care about that. We will let you know the status of this. Best Regards, Pawel Sikorski From: Baptiste Durand [mailto:[email protected]] Sent: Tuesday, November 25, 2014 10:34 AM To: Pawel Sikorski Cc: José Bollo; Bumjin Im; Schaufler, Casey; Bartlomiej Grzelewski; Tomasz Swierczek; [email protected] Subject: Re: [Dev] App Installer WorkShop Status Hi Pawel , I prefers that the installer code will be as possible independent of the Launcher and Renderer (here crosswalk). I agree to reuse code yes, but I prefers to import them without especially deps to Google stack. Indeed signature check are also need for Native apps so having a feature that depends of a WRT software to do it sounds strange. -> About Encryption feature : -> The AES key in crosswallk are not managed yet by the key-manager correct? -> I'm wondering if can reuse the code of wrt-installer part instead? To be reasonable, I thinks we need to proceed in two steps: In a first step, to go faster, as Chromium has a feature already integrated for this we can have a binary developed in the crosswalk source code that encrypt the app file for the installer, that permits to have the feature encryption. We need to be sure AES Key used by crosswalk will be managed by key-manager. And this permits to let time to develop 2nd step : i.e have a definitive solution without Google stack. Pawel, do you agree with this plan for the encryption feature? Thanks for your answer/ BR Baptiste 2014-11-25 10:01 GMT+01:00 Pawel Sikorski <[email protected]>: Hi Jose, All, Thanks for the answer and points. Yes, I understand your points and agree with them. Having common installer will simplify the architecture here. Keeping the privilege level extraction/verification will be also easier to prepare. We already have some code in crosswalk, that can be used here. It is thanks to Zhang, Xu U [[email protected]] :)! >>Hi Baptiste, >> >>I have implemented some features on Crosswalk installer, I think they may be >>useful for your reference. >>1. https://github.com/crosswalk-project/crosswalk/pull/2518. >>For this pull request, it implement the features below: >>* Parser Tizen privileges from config.xml of wgt >>* Register application’s permission to Cynara policy >>* Call security manager to set smack label for files in the widget >>I think you can use some code directly and send pull request in Tizen gerrit >> >>2. https://github.com/crosswalk-project/crosswalk/pull/2169 >>https://github.com/crosswalk-project/crosswalk/pull/2291 >>https://github.com/crosswalk-project/crosswalk/pull/2422 >>For these pull requests, they implemented features Tizen widget signature >>checking >> >>Best Regards >>Zhang Xu >> Thank you Zhang Xu for the info. >>HERE IS THE QUESTION: Is the computation of the privilege level based on >>the signature chain used only in installers? I do not know any other places, but I cannot be sure, that there none. Sorry. Best Regards, Pawel Sikorski -----Original Message----- From: José Bollo [mailto:[email protected]] Sent: Monday, November 24, 2014 5:25 PM To: Pawel Sikorski; Bumjin Im; Schaufler, Casey Cc: 'Baptiste Durand'; [email protected] Subject: Re: [Dev] App Installer WorkShop Status Hi all, hi Pawel, Le samedi 22 novembre 2014 à 13:54 +0100, Pawel Sikorski a écrit : <snip> > platform/core/security/key-manager <snip> > As for the extraction of signature levels (platform, public, partner), > originally, wrt-installer used a package used cert-svc repository, > module vcore. > > I will discuss this item more with Security Team and let you know the > output. <snip> Thank you for your investigation. I had no time to check today but will try tomorrow... maybe. However, I want to point out the fact that computing the privilege level is a very sensitive operation: it has to be fully trusted. IIRC, the security manager that currently is in charge of recording the privileges in Cynara's database is not checking the level of privileges. Then, any program with the correct privilege for using the security-manager features will be allowed to install an application with any privilege of any level. It is showing how setting a common code for installer is beneficial: all of its derived installer will gain a trusted common piece of code for computing the privilege level. This model is very simple and only needs that installers are trusted. It also requires that API's of security manager are filtered on specific privileges of high level. An other model would be to have a specific service to manage the privilege levels. But this way looks very impractical and should be considered only if the privilege level have to be checked in other places than installers. HERE IS THE QUESTION: Is the computation of the privilege level based on the signature chain used only in installers? I would like to insist on the importance of this aspect of the security. Best regards José Bollo -- Baptiste DURAND Eurogiciel Vannes/FR
digsig_status.ods
Description: application/vnd.oasis.opendocument.spreadsheet
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
