[sv-bc] Protect Tool Directives - Few queries.

Hi,

 

Considering the relax rules and checks we have in SV-LRM regarding
protect-tool directives, I am curious if following user scenario is
considered - 

 

Let's say an IP Provider (say - IPP1) has 2 encryption envelopes in a
file (say file1) and he uses a tool to encrypt this file and to produce
an encrypted file called e_file1. This tool uses the flexibility
provided in SV-LRM and it writes key-block-directives for decryption
envelope corresponding to 1st encryption envelope (say - DEC_ENVLP_1)
but it does not write key-block-directives for decryption envelope
corresponding to 2nd encryption envelope (say DEC_ENVLP2). IPP1 packages
e_file1 as IP1 and ships it to its customers. 

Now, one of the customers of IPP1 is another IP Provider (say IPP2) and
he uses IP1. He has file (say file2) and this has, once again, two
encryption envelopes - out of which RTL in first encryption envelope
consist "`include e_file1". This file (file2) is once again encrypted
using the same tool that uses flexibility provided in LRM, and produces
e_file2. So, e_file2 has two decryption envelopes (say DEC_ENVLP3 &
DEC_ENVLP4) - first one has key-block-directives and the second one does
not have key-block-directives. IPP2 packages efile2 as IP2 and ships it
to its customers.

 

Now, according to LRM protect-tool-directives are valid until those are
overridden by a new value or those are reset using reset-directive. So,
a tool may be tempted to update the decrypt-directives as and when it
encounters it and uses the information already present in OM to decrypt
cipher-text. But this would possibly be incorrect. I am trying to
explain it here - 

When a customer uses this IP2 in his design and tries to synthesize it,
the synth-tool parses e_file2 and when it gets protect-tool directives
in DEC_ENVLP3, they are populated in OM and are used to decrypt it to
populate RTL that contains "`include e_file1". The synth-tool now parses
this RTL and when it reaches this `include it starts parsing RTL present
in e_file1 and when it comes to DEC_ENVLP3, it parses protect-tool
directives and updates OM and then uses this updated OM to decrypt and
parses the RTL that we get after decryption of DEC_ENVLP3. As we
continue to parse RTL, we reach DEC_ENVLP4 and since it does not have
key-block-directives, we'll use information that is already present in
OM to decrypt DEC_ENVLP4 and parse the RTL that we get from it. Once we
are done with e_file2, we go back to parsing of e_file1 and we come to
DEC_ENVLP2. Once again, it does not have key-block-directive so it will
use the information already present in OM. But this would be incorrect.
Isn't it? We need to use key-block-directives that were present in
DEC_ENVLP1. 

 

If we do intend to have incomplete decryption envelopes that will borrow
directives from previous decryption envelopes, a tool need to keep stack
of set of directives based of level of nesting of decryption envelopes. 

 

Would it not be a cleaner and easier to use approach to impose the
restriction that a decryption envelope need to be 'complete' and it will
neither borrow any directive from any previous envelope nor it will lend
any to any envelope that comes after it? 

 

 

Similarly for encryption envelopes - If one can elaborate on the user
scenarios because of which SV-LRM allows any protect-tool-directive to
come almost anywhere and in no particular order in the design file, it
will help me understand it better. Also, will it any negative
repercussions on any of the user scenarios, if following restrictions
are imposed-

1.	All the key block directives (that are required for encryption
of symmetric key using asymmetric encryption) should come together.
2.	This 'set' of key-block directives should have a marker for
beginning and end. E.g. let's say that key_owner should be the first
directives and any key-block-directives that follow this directive will
belong this 'set' until we hit another 'key_owner' directive. --- OR ---
This set of key-block-directives should follow a particular order. [This
option is for consideration of gentlemen in this forum. In LRM, we would
have only one of these two options]
3.	The directives that contain information about 'data' (i.e. RTL
that is to be encrypted) should come together. (e.g. data_method and
data_keyname)

 

If LRM imposes these restrictions, 'exchange-keys' for multiple tools
can also be supported. 

 

Please let me know your thoughts on these. 

 

Thanks & regards,

-Gauraw

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.