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 [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
