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

I think you will find the P1735 working group better positioned to
review this issue and offer a recommendation.  I can add it to our
agenda for consideration, but a referral action from SV-BC and P1800
would be a helpful formality.

/sjd


Chandel, Gauraw wrote:
>
> 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 1^st encryption envelope (say –
> DEC_ENVLP_1) but it does not write key-block-directives for decryption
> envelope corresponding to 2^nd 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* <http://www.mailscanner.info/>, and is
> believed to be clean. 

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