P1735Minutes2008Aug13 < P1735

P1735 Web>P1735PublicDocuments>P1735Minutes2008Aug13 (2008-09-03, StevenDovich) (raw view)EditAttach
---++ IEEE P1735 Working Group Meeting of August 13, 2008 

---+++ Meeting Info 

[[P1735MeetingInfo][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
   1 [[http://standards.ieee.org/board/pat/pat-slideset.pdf][Patent slides]]
   1 Approve agenda
   1 Approval of Meeting minutes from 8/6/2008
   1 Action Items Status
   1 Liaison Reports
   1 Cross-region Protection Issues
   1 License Management
   1 Other Business

---+++ Minutes 

---++++ Attendance/Quorum 
We have 3/4 eligible entities, and have a working quorum.

---++++ Patent Policy 
 The [[http://standards.ieee.org/board/pat/pat-slideset.pdf][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 [[P1735Minutes2008Aug6][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:

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

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.
   1 What ways can regions be used? How are they affected by protection?
   1 How will access restrictions affect how IP authors write their IP?
   1 How will access restrictions affect how IP users can use the IP?
   1 Is obscurity sufficient? Where is the line drawn between information needed to use a model and information needed to reverse engineer a model?
   1 What are the advantages of restricting access?
   1 What are the reactions to the trade-offs of restricted access versus usability?
   1 What access should be provided to a protected region?
   1 Input from IP providers.
   1 What have the reactions been to the encryption  VHDL and Verilog?

</blockquote>

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
<blockquote>
<verbatim>
From: Michael Smith <Michael.Smith_at_.....>
Date: Wed Aug 13 2008 - 08:59:53 PDT
</verbatim>

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?
</blockquote>



---++++ 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 [[P1735Minutes2008Aug27][August 27, 2008]] meeting.

-- Main.StevenDovich - 27 Aug 2008
Topic revision: r3 - 2008-09-03 - 14:45:20 - StevenDovich
P1735