Support IEEE 1735 encryption standard - Revision history

Vince at 20:28, 29 October 2024

2024-10-29T20:28:39Z

Vince at 16:35, 29 October 2024

2024-10-29T16:35:18Z

Hoa at 05:27, 25 July 2024

2024-07-25T05:27:36Z

Hoa at 18:58, 31 August 2018

2018-08-31T18:58:39Z

Hoa: Created page with "'''Q:Does Verific provide support for IEEE 1735 encryption standard?''' Verific does not implement the decryption/encryption algorithms. This task is appropriately reserved t..."

2018-08-31T01:03:02Z

Created page with "'''Q:Does Verific provide support for IEEE 1735 encryption standard?''' Verific does not implement the decryption/encryption algorithms. This task is appropriately reserved t..."

New page

'''Q:Does Verific provide support for IEEE 1735 encryption standard?'''

Verific does not implement the decryption/encryption algorithms. This task is appropriately reserved to the licensee. Verific, however, does provide APIs with which the licensee can plug in their proprietary decryption/encryption.

For technical details, please see:

http://www.verific.com/docs/index.php?title=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 distribution:

examples/verilog/parse_encrypted_RTL
examples/verilog/parse_encrypted_RTL_1735style

← Older revision		Revision as of 20:28, 29 October 2024
Line 26:		Line 26:

	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.

@@ Line 2: / Line 2: @@
-''Note: This article mentions only "encryption/decryption '''algorithms'''," but the same arguments also apply to "decryption/encryption '''keys'''."''
+''Note: This article mentions only "encryption/decryption '''algorithms'''," but the same arguments also apply to "encryption/decryption '''keys'''."''
-Verific provides APIs with which the licensees can plug in their proprietary encryption/decryption algorithms.
+Verific provides APIs with which our licensees can plug in their proprietary encryption/decryption algorithms.
 For technical details, please see:
@@ Line 12: / Line 12: @@
 (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_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, Verific 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 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, it would ship the same implementations to all of its licensees. Many licensees of Verific are direct competitors. A company would not want its competitors to have access to its 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 the provider of encryption/decryption algorithms, Verific would be responsible for providing measures to prevent security breaching. Since the encryption/decryption implementations were 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 the responsibility.
+* 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.

@@ Line 1: / Line 1: @@
-'''Q:Does Verific provide support for IEEE 1735 encryption standard?'''
+'''Q: Does Verific provide support for IEEE 1735 encryption standard?'''
-Verific does not implement the decryption/encryption algorithms. This task is appropriately reserved to the licensee. Verific, however, does provide APIs with which the licensee can plug in their proprietary decryption/encryption.
 For technical details, please see:
@@ Line 12: / Line 16: @@
      examples/verilog/parse_encrypted_RTL
      examples/verilog/parse_encrypted_RTL_1735style

@@ Line 5: / Line 5: @@
 For technical details, please see:
-http://www.verific.com/docs/index.php?title=Parsing_Protected_and_IEEE_1735_Encrypted_RTL_Files
+[http://www.verific.com/docs/index.php?title=Parsing_Protected_and_IEEE_1735_Encrypted_RTL_Files Parsing Protected and IEEE 1735 Encrypted RTL Files]
 (contact Verific Tech Support if you don't have credentials for Verific Documentation).