P1735UseCases < P1735

P1735 Web>P1735GroupPrivateWorkspace>P1735UseCases (2011-09-30, JohnShields) (raw view)EditAttach
---++!! Use Cases

%TOC%

---+++ Digital Envelope
---++++ Assumptions

All tools are standards compliant with respect to encryption/decryption pragmas. Examples will be provided by P1735 to illustrate use cases in detail separately. P1735 public key management strategies will be defined separately.

---++++ Description

An IP author protects their IP with an encryption tool and enables a set of decryption tools to process that IP. The presumption is that the set of tools supports one or more complete design flows for that IP author's prospective users. The IP author obtains or is supplied a public key for each tool. A set of tools from a single vendor may employ a single public key for convenience. The public key management strategy shall be one of the recommended P1735 strategies. The manner in which such public keys are obtained, the set of tools they apply to, key expiration, etc. are described in such a strategy.

The encryption tool is required to support one time session key generation using any of the P1735 required symmetric ciphers. IP data will be protected with the session key. For each public key provided, the session key will be encrypted using that public key. This creates a set of digital envelopes that may only be "opened" by the owners of those public keys. These digital envelopes are part the protected IP delivered to IP Users.

The decryption tool supports the P1735 required symmetric ciphers, in particular to use the session key to decrypt the IP. In addition, it has secure access to the private key associated with at least one of the digital envelopes. The flow supports delivery of protected IP directly to IP users from the IP owner or via any 3rd party at the IP owner's discretion. Any tool in the set of enabled tools may be used with that protected IP.

This use case specifically uses public/private keys to avoid requiring the IP owner to distribute keys to IP users or tool providers. IP users have no keys to receive or manage. Tool providers need only make public keys available to IP owners for use during encryption. The session key and recommended symmetric ciphers insure strong encryption and fast enough decryption to be suitable for the large amount of data involved in typical IP.

This use case does not limit access to specific IP users. On the contrary, it limits use to specific tools for their intended purpose only. Other mechanisms may be used in conjunction with the digital envelope model to limit use. A licensing mechanism may be used to restrict use to licensed IP users only. Rights management may be employed to limit what specific tool are allowed to do with protected IP in terms of processing and derived outputs. Here, these are considered orthogonal issues.

A statement about the use of digital signatures for IP authentication is needed. It is a likely detail to this use case or acceptable optional variation. Digest algorithm recommendations, encryption tools being able to use an IP owner secret key, and IP owner public key distribution are needed for use of signatures to be interoperable.

---++++ Restrictions

While the concept of digital envelopes may be broadly applied to other encryption/decryption scenarios, the use case description here is meant to specific enough to be deployed and achieve the intended interoperability across tools. The use of a symmetric cipher and its secret key to protect the session key in an envelope is not acceptable in this use case. The use of supplied secret key by either the IP owner or the encryption tool itself to replace the one-time generated session key is not acceptable in this use case. See Note 1.

---++++ Refinements for IP transforming tools

An IP author protects their IP by encrypting it with a supported symmetric cipher. The key for this cipher is itself encrypted in one or more small digital envelopes. Each uses a supported asymmetric cipher and a public key that was published or otherwise made available by the vendor of the EDA tool that will read it. Each digital envelope is private to the consuming EDA tool and cannot be read by other EDA tools. This will be important in the case that information beyond the symmetric cipher key is included in the digital envelope.

EDA tools fall into two classes: those that only read IP, and those that both read and write IP. A simulator is a good example of the former and a synthesis tool is a good example of the latter.

For EDA tools that only read IP, the digital envelope use case is covered in detail separately.

For EDA tools that both read and write IP, the output is expected to include either the original or transformed IP according to methods specified by the IP author. The mechanism for specifying these methods is part of "rights management" and is not covered in this use case document. Assuming the method is to preserve protection with encryption, the IP output is expected to be encrypted with the same session key and cipher as used to read it, and all digital envelopes are expected to be copied verbatim from input to output. This allows other EDA tools to read the IP. Digital envelopes may not be reconstructed as the content is private and no assumption can be made about the availability of other tool public keys, which are required to create an envelope.

Note that with at least one EDA tool that both reads and writes, the number of possible flows is infinite. Assume four digital envelopes for simulator A, simulator B, synthesis tool C, and synthesis tool D. User flows include: IP -&gt; C -&gt; A and B IP -&gt; C -&gt; C -&gt; D -&gt; C -&gt; B

---++++ Notes

   1 It doesn't matter that these restricted variations are allowed by the standard pragmas or that they may have some value. Here they are considered inferior, if not bad, practice in terms of key management. If they are justified in terms of both value and acceptable key management practice, a new use case (referenced as a variation of this basic use case) may be added to explain the details.
---+++ Digital Envelope with Licensing
---++++ Assumptions

This use is a variation on the primary digital envelope use case described above. It incorporates the assumptions and description of that use by reference.
---++++ Description

The digital envelope use case is a primary use case and the only use case that supports interoperability across tool flows. . It allows an IP author to authorize a set of tools to work with their encrypted IP. There is nothing in that use case that limits use to particular users. P1735 regards licensing as the mechanism to restrict use to particular users. There is no other mechanism for this purpose under consideration either. All of the issues for the IP author and IP user are common to those found in the conventional licensing of software.

The digital envelope use case with licensing will allow IP authors to restrict access to their protected IP to both a set of tools and users. The tools are authorized by proxy to work with the IP. The tools will further limit access to those users who present valid licenses provided to them by the IP author. The security and flexibility of the license check has clear tradeoffs for the IP author. The required support for licensing that a tool provider must support is the external licensing mechanism as described elsewhere in P1735. The IP author must deliver a license service as part of their IP, if they wish to use the external licensing mechanism. There is the possibility of an internal licensing mechanism provided by a tool vendor. For purposes of this use case, either licensing mechanism meets the objective of limiting IP access to licensed users. Only the external licensing mechanism, by virtue of being required of all tool providers and in the control of the IP author to deliver, has the potential of being interoperable across an arbitrary set of compliant tools.

The protocol for expressing what license to check, when it is checked, and how the tool vendor accesses the license service is defined in the external licensing mechanism. The documentation for this use case in the P1735 recommendation should have a straightforward example of the digital envelope use case with external licensing. The licensing mechanism detailed recommendations are defined separately from use cases.
---++++ Notes

It is worth noting that the existing license pragma in 1800 and 1076 will be recommended to be deprecated in favor of an improved licensing proposal from P1735. There is a better balance we are trying to strike between the quality of license checking in terms of security and feature richness and cost to the IP author (and tool vendors, too) to deliver and deploy it. There were some ideas prompted by discussion of this use case about the various forms an external or internal licensing service might take. All those ideas should be addressed in the [[P1735LicenseManagement][licensing]] or [[P1735RightsManagement][rights management]] sections of P1735.  (TBD We need to unify the control block and rights management sections.) -- Main.JohnShields - 2011-09-30

---+++ Tool-based Secret Key
---++++ Assumptions

All tools are standards compliant with respect to encryption/decryption pragmas. Examples will be provided by P1735 to illustrate use cases in detail separately.
---++++ Description

In this scenario, the tool provider has both encryption and decryption tools that have a proprietary secret key for a symmetric cipher built-in to the tools. The IP owner has no key management responsibilities. They protect their IP using an encryption tool and it may subsequently be used by any of that tool provider's decryption tools that have access to the same secret key.

This use case is roughly equivalent to the historical `protect mechanism in the Verilog language. It is a proprietary solution and will not allow the protected IP to be used in a general tool flow, unless all tools are provided by the same tool vendor. It's only advantage is the convenience to the IP owner of not having to deal with any encryption keys.

---++++ Related Use Cases

The digital envelope use case may serve a similar role by simply choosing only the public key of a single vendor. That is unlikely to be a key management burden in that vendor's encryption tool.

---++++ Proposed Value Judgement for P1735

P1735 will make recommendations both for good practices and against bad practices. There is no reason to expect this use case won't be made available by tool vendors and there is nothing wrong or more risky with the security of this use case vs. others we recommend, e.g., the basic digital envelope use case. Nevertheless, this use case is both proprietary and not extensible. It does not meet some of the goals of P1735's PAR. We can explain the use case in the standard, but we should recommend against using it.

---+++ Secure Keyring

---++++ Background

Encryption keys for modern ciphers are typically long binary numbers, from 100s to 1000s of bits in length. In the directives for IP protection in 1076, 1364, and P1735, a key is a named item. In general, the unique name for a key is a tuple of the keyowner and keyname. Depending on the use case, an IP owner may have a number of keys to refer to in directives to describe the encryption scenario for their IP. For example, in the digital envelope basic use case, the IP owner needs to refer to the public key for each tool across the suite of tools being enabled. Keeping track of key references is one thing. Managing the actual keys is another. One possible and portable approach is to provide the actual key in a directive. This is an encoded binary string, the text of which is a field of the directive. If one is managing a set of text snippets, one for each key, that will be composed with IP as input to an encryption tool, that might become tedious and error prone. There is some increased risk of compromise, though, if all the keys are public keys, that is of no consequence. If any of the keys are secret keys, there is a concern.

On the one hand, all of key handling described above takes place within the security of the IP owner's environment. On the other, without due diligence, those snippets are open secrets that could find there way via file backup/restore, email, or even a handwritten copy out of the IP owner's secure environment. Going a step further, if one wishes to move secrets like this between stakeholders according to some use case, then a better means than handling text snippets is needed.

---++++ Description

The metaphor of a keyring as a holder for a number of keys is a useful concept for keeping track of encryption keys. The idea of a secure keyring is to provide protection for the keyring such that only an authorized user/application may access the keys. A keyring is a persistent repository for keys. Utility software for a keyring should allow a user to create a keyring, add to or delete keys from it, query what keys are on the keyring, etc. An encryption program that supports a keyring is able to access keys referenced in encryption directives directly from the keyring. An IP owner would create a keyring and add keys appropriate to the desired use case for encryption, construct the encryption directives as appropriate, and encrypt the IP.

A secure keyring is a keyring that is protected from unauthorized use by some means. One mechanism, password or passphrase protection, requires the user of the keyring to provide a password to access keys. A utility or encryption program using a secure keyring would require a proper password before access to a key from its store is granted. A decryption tool accessing such a secure keyring would also behave in this manner, expecting its user to know the passphrase. The granularity of protection may be at the individual key or any key on the keyring.

A related, but conceptually alternative, mechanism for protecting a keyring is to encrypt it using the digital envelope concept. Here a keyring is created and encrypted with a public key for secure delivery of the keyring to the owner of the public key. This can be done with any general encryption tool and then be decrypted upon delivery before using it. Here, the idea is that the tool has been designed to directly access the encrypted keyring.

---++++ Role of Secure Keyrings in P1735 Use Cases

How might secure keyrings fit into the standard IP encryption mechanisms and P1735 use cases for them?

There is nothing explicitly stated about requiring support for the use of keyring mechanisms in the existing 1076 or 1800 standards for IP protection. Nevertheless, their use is implied when keys are referenced by name but not required to be provided directly in the encryption input. An encryption tool may optionally provide such a mechanism as a convenience to its users as a competitive advantage. A decryption tool must manage its secret or secrets in a private, secure manner. It may harden such secrets directly into its software or use an external persistent storage scheme. Thus a decryption tool may be conceived of as privately using its own secure keyring today. Beyond this, there are interesting use cases that can be described if secure keyrings are made an explicit feature of tools.

For example, a keyring may be created by an IP owner and secured for use by a specific tool provider. There is a feature of the tool to be told to search for keys from a specific secure keyring or keyrings. Now it becomes possible for the IP owner to deliver a secure keyring to specific IP users along with their IP. Both the keyring and the IP remain secure, but the user may use the IP with appropriate tools, as the IP owner intended. And the tool provider does not have an IP owner secret in its possession either.

---++++ Other Concerns

A keyring is really a database for storage of named binary items. There is no expectation that keyrings will exist in a standard format that tools may access, be built used common technology, etc. As detailed use cases are considered, the inevitable concern of different tools needing their keyrings populated with appropriate keys will arise. It must be possible for authorized users of a keyring to import and export keys from a keyring in a standard format.

---+++ IP Author Secret Key

---++++ Background

Secret keys created by an IP author were originally used as the only option for secure data exchange, and the control of their own secret key continues to provide a sense of security for IP authors. Secret key cryptography also continues to provide several advantages over public key cryptography: encryption and decryption are faster (though this is easily addressed by using a session key with public key cryptography), and it provides an additional layer of protection on who can decrypt the author's IP (the user must have the decryption key in addition to the file).

In cases where an author's secret key is individually provided to the user and the author and user are co-operating, that additional layer of protection is real. However, in the case of IP protection, where the author and user aren't necessarily co-operating and we also wish to provide ease-of-use, the use of an IP author created secret key provides no extra protection. Any methods that would allow an IP author to transmit a key to a user without having direct access to their EDA tools would also allow the user to retransmit the key, unless steps are taken to restrict who can use the key. Such steps would essentially involve license management. We hope to simplify the problem of license management by separating its enforcement from decryption. Therefore the use of an IP author secret key adds no additional security and will not be recommended.

---++++ Description

This use case is intended for use in communicating between an IP provider and a tool which does not have a published public key. As with all of the recommended use cases described in this recommendation, the underlying data is assumed to be encrypted with a symmetric encoding for reasons of performance and cross tool transportability.

This use case facilitates providing encrypted IP to users with tools that differ from the IP author's tool. It involves an IP author, one or more IP users, and their trusted/certified decryption-enabled tools. A key exchange method is also required to transfer the IP author's decryption key (a secret key for symmetrical ciphers, a private key for asymmetrical ciphers) to each IP user's decryption-enabled tools.

The IP is encrypted with the public or secret key of the IP author; the key is securely provided to the decryption-enabled tool via a key exchange method if not already available to the tool within a secure local database; the file is sent to each IP user. The IP user executes the file using the decryption-enabled tool, which decrypts the file using the IP author's private or secret key. This method may be used for a key block within a digital envelope.

The key exchange method requires that each decryption-enabled tool vendor provides a key exchange utility (e.g. an executable) to IP authors that accepts a privet or secret key and creates an encrypted package that contains that key, and is readable only by that vendor's tools. The IP author uses the key exchange utility to package the IP author's private or secret key for an IP user's decryption-enabled tool and sends the package (via any distribution mechanism) to the IP user. The IP user instructs his decryption-enabled tool to read the package into a secure local key repository.

-- Main.StevenDovich - 02 Jul 2008
Topic revision: r5 - 2011-09-30 - 19:30:04 - JohnShields
P1735