gah, I missed this thread, apologies. Sounds like a lot has been already discussed. One thing that comes to mind is that CI I am sure are already signing artefacts somehow (they do this for builds), maybe some of this could be of us?
Aric / Fatih , any comments? On Sat, Jan 14, 2017 at 4:55 PM, Lincoln Lavoie <[email protected]> wrote: > Hi Leo, > > Correct, but the "scripts" generate the report and if they include a call > to a binary executable (provided by OPNFV with an included > private/protected key), that binary would sign the report, after include > the hash of the scripts. Any changes, including injecting something into > the report before the signing operation, would cause the hash to change and > invalidate the report. Again, I think this is about integrity of the > report/results, not about encrypting the results. If a user/tester wants > to encrypt their results, they can do that on their own, after the results > are generated, since that would likely require a key (or password) exchange > with the final recipient of the results. To build in that key exchange > into the Dovetail process will be very complex (IMHO). > > Also, as identified early, the binary could be used by other projects to > sign their output as well, which makes for a repeatable / valuable tool for > the industry. > > Cheers, > Lincoln > > On Fri, Jan 13, 2017 at 8:36 PM, Leo Wang <[email protected]> wrote: > >> I guess we have some misunderstanding about this report. >> >> The report is a dynamic generated file, it is not a part of the release, >> or a static certificated file delivered from OPNFV(we do may have this >> final certificate file, but that’s total a different thing ) >> >> User get dovetail tool to run tests, then they get a report about this >> test, they have a total control of the report, before they upload the >> report to OPNFV, they can do anything with it. >> >> >> >> On Jan 13, 2017, at 16:42, Yujun Zhang <[email protected]> wrote: >> >> Based on my limited knowledge, a user can only sign the result with *his >> own* private key. It is not possible for him to modify a report signed >> by let's say *OPNFV release bot* and kept the original signature. >> >> On Fri, Jan 13, 2017 at 4:38 PM Leo Wang <[email protected]> wrote: >> >>> Hi Lincoln >>> >>> I agree with you , your proposal can keep the integrity of the dovetail >>> tool(scripts/codes), >>> >>> but i not sure that the content of results is right. >>> >>> to sign the result can only proof its integrity that result is not >>> tampered with during the transfer or uploading >>> >>> If user modify the result right after the result being generated then >>> sign the result >>> >>> how to tell whether the result is the original one or not ? >>> >>> >>> BR >>> >>> Leo Wang >>> >>> >>> >>> >>> On Jan 13, 2017, at 06:08, Lincoln Lavoie <[email protected]> wrote: >>> >>> Hi Leo, >>> >>> It may be worth separating the encryption from the signature piece. I >>> believe the primary purpose of the security requirements were to ensure the >>> integrity of the testing (i.e. the dovetail tests were not modified by the >>> tester, to "solve" a failure). In this process, I don't believe that is >>> accomplished, because the scripts are generating their own key each time. >>> I think this will also lead to a nightmare number of keys that have to be >>> kept, maintained, and tracked to look at results run in the past. >>> >>> Attached is a different approach. This approach would only sign the >>> results, which protects their integrity compared against the scripts that >>> were used to generate the results. If a user wanted to "protect" their >>> results, I would leave it to them to encrypt them and share keeps with the >>> expected "consumer." In this approach, OPNFV Staff would be responsible >>> for maintaining the public / private key (which should likely be updated >>> with each release. That key is used, along with a hash (MD5 sum or >>> similar) of the Dovetail "scripts" to sign the results. That signature can >>> then be validated against the public key, to ensure the scripts or results >>> were not tampered with prior to review. This approach assumes the trust is >>> placed with the OPNFV staff, in building (compiling) the integrity tool w/ >>> the private key, and providing only the compiled version with each release >>> (private key would have be protected within that tool). >>> >>> The "gotcha" is making sure that compiled tool can run on all platforms >>> and ensuring the private key is well protected. And, if the OPNFV staff >>> are able to maintain the set of keys, etc. >>> >>> >>> >>> Thoughts? >>> >>> Cheers, >>> Lincoln >>> >>> >>> On Thu, Jan 12, 2017 at 4:46 AM, Leo Wang <[email protected]> >>> wrote: >>> >>> Hi, Luke and Lincoln, >>> >>> >>> Dovetail team plans to add this feature to dovetail tool , and need your >>> professional advices from security group and 3rd party lab, >>> >>> so would you guys take a time to review this idea? >>> >>> >>> Thank you both in advance ! >>> >>> >>> I’ve update the diagram with digital signature, and both encryption and >>> digital signature can be optional to fit in user’s demand >>> >>> for details, please check this link: >>> https://wiki.opnfv.org/display/dovetail/Dovetail+Security+of+Report >>> >>> <encryption and digital signature (2).png> >>> >>> >>> On Dec 27, 2016, at 18:00, Lijun (Matthew) <[email protected]> >>> wrote: >>> >>> digital signature should be added to do integrity checks, etc. +1. >>> >>> /MatthewLi >>> *发件人：*Leo Wang >>> *收件人：*Yujun Zhang >>> *抄送：*Motamary, Shabrinath via opnfv-tech-discuss >>> *时间：*2016-12-27 16:32:46 >>> *主题:*Re: [opnfv-tech-discuss] [dovetail]Dovetail encryption for report >>> >>> Encryption or signature or certificate do have different role in this >>> big picture, >>> >>> It can be done step by step. >>> >>> >>> >>> >>> On Dec 27, 2016, at 16:01, Yujun Zhang <[email protected]> wrote: >>> >>> On Tue, Dec 27, 2016 at 3:54 PM Leo Wang <[email protected]> wrote: >>> >>> As i mentioned , someone did show their concern on the security of test >>> report, so dovetail will provide this optional parameter for them >>> >>> digital signature is used to identify the source and its integrity, and >>> surely it can raise the security level, or even better to get a digital >>> certificate to make it more secure? >>> >>> >>> Sure. >>> >>> You may refer the international standard ISO/IEC 17065 on how to >>> certify a product. The standard is not about technical solution but quality >>> processes and organizations. >>> >>> Encryption or signature are all technical methods to enhance the >>> authority of a certification program. >>> >>> >>> >>> >>> >>> >>> -- >>> ************************************************************ >>> ******************* >>> *Lincoln Lavoie* >>> Senior Engineer, Broadband Technologies >>> >>> <https://www.iol.unh.edu/> >>> www.iol.unh.edu >>> 21 Madbury Rd., Ste. 100, Durham, NH 03824 >>> Mobile: +1-603-674-2755 <(603)%20674-2755> >>> [email protected] >>> <http://www.facebook.com/UNHIOL#> <https://twitter.com/#!/UNH_IOL> >>> <http://www.linkedin.com/company/unh-interoperability-lab> >>> >>> Ars sine scientia nihil est! -- Art without science is nothing. >>> Scientia sine ars est vacua! -- Science without art is empty. >>> ************************************************************ >>> ******************* >>> >>> <OPNFV_Dovetail_Signed_Results.png> >>> >>> >>> _______________________________________________ >>> opnfv-tech-discuss mailing list >>> [email protected] >>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>> >> >> > > > -- > ************************************************************ > ******************* > *Lincoln Lavoie* > Senior Engineer, Broadband Technologies > > <https://www.iol.unh.edu> > www.iol.unh.edu > 21 Madbury Rd., Ste. 100, Durham, NH 03824 > Mobile: +1-603-674-2755 <(603)%20674-2755> > [email protected] > <http://www.facebook.com/UNHIOL#> <https://twitter.com/#!/UNH_IOL> > <http://www.linkedin.com/company/unh-interoperability-lab> > > Ars sine scientia nihil est! -- Art without science is nothing. > Scientia sine ars est vacua! -- Science without art is empty. > ************************************************************ > ******************* > > _______________________________________________ > opnfv-tech-discuss mailing list > [email protected] > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > -- Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat e: [email protected] | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44 12 52 36 2483
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
