Difference between revisions of "Support IEEE 1735 encryption standard"
| (One intermediate revision by the same user not shown) | |||
| Line 2: | Line 2: | ||
| − | ''Note: This article mentions only "encryption/decryption '''algorithms'''," but the same arguments also apply to " | + | ''Note: This article mentions only "encryption/decryption '''algorithms'''," but the same arguments also apply to "encryption/decryption '''keys'''."'' |
| − | Verific provides APIs with which | + | Verific provides APIs with which our licensees can plug in their proprietary encryption/decryption algorithms. |
For technical details, please see: | For technical details, please see: | ||
| Line 12: | Line 12: | ||
(contact Verific Tech Support if you don't have credentials for Verific Documentation). | (contact Verific Tech Support if you don't have credentials for Verific Documentation). | ||
| − | There are application examples in Verific distribution: | + | There are application examples in Verific's software distribution: |
examples/verilog/parse_encrypted_RTL | examples/verilog/parse_encrypted_RTL | ||
examples/verilog/parse_encrypted_RTL_1735style | examples/verilog/parse_encrypted_RTL_1735style | ||
| − | Verific does not implement nor provide encryption/decryption algorithms for several reasons: | + | Verific does not implement nor provide our own encryption/decryption algorithms for several reasons: |
| − | * If Verific were to provide encryption algorithms, | + | * If Verific were to provide encryption algorithms, we would have to provide the decryption algorithms. Verific has always been shipping source code and is not set up to ship binaries. If Verific shipped the implementations of the encryption/decryption algorithms in the form of C++ source code, that would defeat the purpose of encryption in the first place. |
| − | * If Verific provided encryption/decryption algorithms, | + | * If Verific provided encryption/decryption algorithms, we would ship the same implementations to all of our licensees. Many licensees of our licensees are direct competitors of each other. A company would not want its competitors to have access to its encryption/decryption algorithms. |
| − | * As | + | * As a provider of encryption/decryption algorithms, Verific would be responsible for providing measures to prevent security breaches. Since the encryption/decryption implementations would be shipped to multiple licensees, there would be no guarantee that the algorithms would enjoy the same protection as the licensees' IPs would. It is not fair nor practical to expect Verific to bear this responsibility. |
So the task of encryption/decryption implementations is appropriately reserved to the licensee. | So the task of encryption/decryption implementations is appropriately reserved to the licensee. | ||
| + | |||
| + | |||
| + | '''Mixing preprocessor directives and encryption blocks''' | ||
| + | |||
| + | The IEEE-1735 LRM is not clear about the precedence of protected blocks and `ifdef macros. In fact there is a suggestion in Annex C.3 to ''not'' mix encrypted blocks and macros since the behavior could be ambiguous: | ||
| + | |||
| + | ''The SystemVerilog language has non-pragma preprocessor block syntaxes such as text-replacement macro definitions and conditional compilation `ifdefs. There are also known, non-LRM, tool pragma, and smart comment extensions that control behaviors such as coverage and synthesis for blocks of code. The relative precedence of these syntaxes is often unclear and the resulting HDL interpretation may be tool-dependent. HDL authors are advised to avoid these source ambiguities where possible.'' | ||
| + | |||
| + | Lets take this example: | ||
| + | |||
| + | module test ; | ||
| + | `ifdef UNDEFINED_MACRO | ||
| + | `pragma protect begin_protected | ||
| + | `endif | ||
| + | endmodule | ||
| + | |||
| + | For the above code, popular simulators produce ERRORs even if UNDEFINED_MACRO is not defined in the RTL. Apparently, the macro block does not cause the protected area to be ignored even though it is in the inactive region. | ||
| + | |||
| + | Also, both `ifdef and `protected behave like text processing directives. They do not really follow language rules/semantics the way other constructs such as functions/modules, etc., do. For example, a tool that encrypts a design containing a protection envelop does not care about other Verilog constructs including any macros present. This is required so that the encrypted design can still include macros in the encrypted block and can refer to them later when the block is expanded. | ||
Latest revision as of 12:28, 29 October 2024
Q: Does Verific provide support for IEEE 1735 encryption standard?
Note: This article mentions only "encryption/decryption algorithms," but the same arguments also apply to "encryption/decryption keys."
Verific provides APIs with which our licensees can plug in their proprietary encryption/decryption algorithms.
For technical details, please see:
Parsing Protected and IEEE 1735 Encrypted RTL Files (contact Verific Tech Support if you don't have credentials for Verific Documentation).
There are application examples in Verific's software distribution:
examples/verilog/parse_encrypted_RTL examples/verilog/parse_encrypted_RTL_1735style
Verific does not implement nor provide our own encryption/decryption algorithms for several reasons:
- If Verific were to provide encryption algorithms, we would have to provide the decryption algorithms. Verific has always been shipping source code and is not set up to ship binaries. If Verific shipped the implementations of the encryption/decryption algorithms in the form of C++ source code, that would defeat the purpose of encryption in the first place.
- If Verific provided encryption/decryption algorithms, we would ship the same implementations to all of our licensees. Many licensees of our licensees are direct competitors of each other. A company would not want its competitors to have access to its encryption/decryption algorithms.
- As a provider of encryption/decryption algorithms, Verific would be responsible for providing measures to prevent security breaches. Since the encryption/decryption implementations would be shipped to multiple licensees, there would be no guarantee that the algorithms would enjoy the same protection as the licensees' IPs would. It is not fair nor practical to expect Verific to bear this responsibility.
So the task of encryption/decryption implementations is appropriately reserved to the licensee.
Mixing preprocessor directives and encryption blocks
The IEEE-1735 LRM is not clear about the precedence of protected blocks and `ifdef macros. In fact there is a suggestion in Annex C.3 to not mix encrypted blocks and macros since the behavior could be ambiguous:
The SystemVerilog language has non-pragma preprocessor block syntaxes such as text-replacement macro definitions and conditional compilation `ifdefs. There are also known, non-LRM, tool pragma, and smart comment extensions that control behaviors such as coverage and synthesis for blocks of code. The relative precedence of these syntaxes is often unclear and the resulting HDL interpretation may be tool-dependent. HDL authors are advised to avoid these source ambiguities where possible.
Lets take this example:
module test ;
`ifdef UNDEFINED_MACRO
`pragma protect begin_protected
`endif
endmodule
For the above code, popular simulators produce ERRORs even if UNDEFINED_MACRO is not defined in the RTL. Apparently, the macro block does not cause the protected area to be ignored even though it is in the inactive region.
Also, both `ifdef and `protected behave like text processing directives. They do not really follow language rules/semantics the way other constructs such as functions/modules, etc., do. For example, a tool that encrypts a design containing a protection envelop does not care about other Verilog constructs including any macros present. This is required so that the encrypted design can still include macros in the encrypted block and can refer to them later when the block is expanded.
