Implementing Configuration Management System for Software Source Code Control
Learn about the opinions shared by SC.27 WG.3 on DIS 17960, focusing on implementing a Configuration Management (CM) system for controlling software/firmware source code, including code signing and roll-back capabilities. Explore the degree of confidence in achieving integrity and code roll-back, hash strength considerations, and discussions on standardization in CM systems.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Opinion from SC 27 WG 3 on DIS 17960 Contributed by Tatsuaki Takebe Discussed at WG 23 meeting 31
How to implement? CM system (Configuration Management system) Software/Firmware source code should be controlled by the Configuration Management System(CM system). 17960 requires code signing and roll back to a unique version. Roll back is treated in the CM system. If CM system provide signing, 17960 is done by CM system. You can control binary data. Other options: Editor signs the code. Code contains signature. Coder uses tools of signing. Signature is kept elsewhere.
Degree of confidence What do you wish to accomplish by 17960? 1. Integrity? YES 2. Capability that you can roll back code? Capability that somebody can roll back the code Degree of confidence 1: Risk is very low -> Hash is created and not protected 2: Risk is low -> Hash is created and protected by ACL 3: Risk is medium -> Hash is created and signed 4: Risk is reasonable -> Hash is created with signature protected by ACL 5: Risk is high -> Hash is created with signature protected by HSM
Degree of confidence Hash strength Weaker Weak MD2, MD4, MD 5 Med SHA-1 Strong SHA-2 Stronger Checksum SHA-3
What do you wish to accomplish? Do you wish to set a standard to be used in CM system? WG 23 thinks that the mechanisms must cross CM systems, and possibly some parts do not originate in traditional CM systems.
Questions to the SC 27/WG3. The SC 27/WG 3 wishes to control binaries. Binaries are created by compliers or linkers. They put additional info into the binaries. Such as signed info from the source code and additional material Because of the additional info, the same source code will end up in different signatures. Irrelevant, we think, as long as signed and containing signed history To avoid that, compiler vendors have to disclose the binary structures. We think not Is it done generally? Isn t it the company confidential info?
