IEEE P1735 Working Group Meeting of August 13, 2008

Meeting Info

Conference Bridge and Webex

Participants

• Attending
  • Steven Dovich, Cadence
  • Ruchi Tyagi, Cadence
  • Nitin Khurana, Cadence
  • William A Hanna, Boeing
  • Dave Graubart, Synopsys
  • Nick Sgoupis, CAST
  • Michael Smith, Synopsys
  • Parminder Gill, Synopsys

• Not Attending
  • Dave Clemans, Synopsys
  • John Shields, Mentor
  • Meera Srinivasan, Synopsys
  • Syed Huq, Cisco
  • Jim Robinson, Synopsys
  • NSS Subramanian, Cadence
  • David Tran, Synopsys
  • Gary Delp, LSI

Agenda

1. Determine Quorum
2. Patent slides
3. Approve agenda
4. Approval of Meeting minutes from 8/6/2008
5. Action Items Status
6. Liaison Reports
7. Cross-region Protection Issues
8. License Management
9. Other Business

Minutes

Attendance/Quorum

We have 3/4 eligible entities, and have a working quorum.

Patent Policy

The Patent slides were offered for review.

No new claims were disclosed at the call for essential patent claims.

Agenda Approval

Motion by Dave G., seconded by Bill. Motion is approved.

Previous Minutes

Michael moved and Dave G. seconded the approval of the August 6, 2008 minutes. The motion was approved.

Action Item Review

Steven reviewed the open action items.

Liaison Reports

CAG report.

Cross-region Protection Issues

Discussion continues from the last meeting using the following set of questions from Michael:

From: Michael Smith <Michael.Smith_at_.....>
Date: Mon Aug 11 2008 - 14:03:43 PDT

When a region is encrypted, that implies certain access rights from anywhere outside the encrypted (protected) region, or via other language-defined access methods. This may be as limited as relying on the obscurity of the contents, or more extensive. It may be part of Rights Management.

Questions:

1. Define a protected region in a general sense.
2. What ways can regions be used? How are they affected by protection?
3. How will access restrictions affect how IP authors write their IP?
4. How will access restrictions affect how IP users can use the IP?
5. Is obscurity sufficient? Where is the line drawn between information needed to use a model and information needed to reverse engineer a model?
6. What are the advantages of restricting access?
7. What are the reactions to the trade-offs of restricted access versus usability?
8. What access should be provided to a protected region?
9. Input from IP providers.
10. What have the reactions been to the encryption VHDL and Verilog?

Nick expressed concern that obscurity seems insufficient. Steven described a simple use model involving encryption of an existing model, and asked about expectations for the resulting behavior. Nick and Michael agreed that those expectations are probably at the core of this issue.

Requiring consistent behavior across encryption forces the obscurity (status quo) outcome. Allowing the scope to be affected by encryption will enable securing of the encrypted content to exclusive use by the IP Author, but that will require extensions to describe the relationships between regions. Input from IP Providers will be required to find an acceptable solution.

Bill agreed that from the IP User perspective, as long as the protected IP delivers the promised functionality, the details of how the protection boundary is defined are not as important. He emphasized that flexible delivery in a single distribution is helpful when extending the use of the IP to cover more functionality.

License Management

From: Michael Smith <Michael.Smith_at_.....>
Date: Wed Aug 13 2008 - 08:59:53 PDT

License Management relies on a compliant tool calling an external license manager (a shared library). Instructions for how the tool can call the license manager should be available as part of the encrypted input to the tool.

This approach is susceptible to several attacks:

• If the entry point for the license manager is known (easy on UNIX with nm, can be made more secure on Windows with special options when building and using the DLL), the IP user can create their own license manager to allow access. The VHDL and Verilog LRMs include a return value that the tool can verify against part of the encrypted input for authenticity.
• A man-in-the-middle attack is still possible. The IP user can interpose their own module between the tool and license manager and discover any information passed between them on a successful license acquisition. That information can be used to spoof an authentic license manager as in the example above. To prevent this attack, some shared information must exist between the tool (passed in via the encrypted input) and the license manager, that is not constant.

How can we secure this mechanism while keeping it easy for users?

License management in VHDL specifies runtime and decrypt licenses; that seems to bridge over into Rights Management. How will license management and rights management interact?

Other Business

Adjournment

Motion by Bill, second by Dave G.. Approved by acclamation at 1:04 pm CDT

Approval

These minutes were approved at the August 27, 2008 meeting.

-- StevenDovich - 27 Aug 2008