Based on Draft 3 and 3a work in progress John Shields Mentor Graphics, Inc. P1735 Standard Overview.

Slides:



Advertisements
Similar presentations
Integration of MBSE and Virtual Engineering for Detailed Design
Advertisements

Dave Graubart & Parminder Gill November 1, 2010
1 Software Requirements Specification Lecture 14.
A Use Case for SAML Extensibility Ashish Patel, France Telecom Paul Madsen, NTT.
TM Freescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective.
Typical Software Documents with an emphasis on writing proposals.
ITEC224 Database Programming
Lecture 9: Chapter 9 Architectural Design
1 PAR Presentation DASC meeting at DAC, June 21, 2001 Project title: A standard for an Advanced Library Format (ALF) describing Integrated Circuit (IC)
P1800 Requirements for IP Protection John Shields.
XRules An XML Business Rules Language Introduction Copyright © Waleed Abdulla All rights reserved. August 2004.
SE: CHAPTER 7 Writing The Program
ISO 9001:2008 to ISO 9001:2015 Summary of Changes
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Second Generation Electronic Filing Specifications Legal XML Court Filing Committee April 26, 2004.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Rosetta Study Group Report IEEE DASC. 1. Broad market potential Applications: heterogeneous model integration –ESL, System-Level Design, System Security,
Fall 2004EE 3563 Digital Systems Design EE 3563 VHSIC Hardware Description Language  Required Reading: –These Slides –VHDL Tutorial  Very High Speed.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Working with XML Schemas ©NIITeXtensible Markup Language/Lesson 3/Slide 1 of 36 Objectives In this lesson, you will learn to: * Declare attributes in an.
Requirements Validation
The common structure and ISO 9001:2015 additions
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Software Requirements Specification Document (SRS)
Request approval from DASC for the formation of an IP Encryption Study Group Proposal prepared by: Gary Delp VSI Alliance CTO.
Viewpoint Modeling and Model-Based Media Generation for Systems Engineers Automatic View and Document Generation for Scalable Model- Based Engineering.
® IBM Software Group © 2009 IBM Corporation Viewpoints and Views in SysML Dr Graham Bleakley
 System Requirement Specification and System Planning.
© Synopsys IP Licensing Recommendations for P1735 Rev 4/16/12.
IEEE Std Proposed Revision Purpose, Scope & 5 Criteria.
SUBJECT : DIGITAL ELECTRONICS CLASS : SEM 3(B) TOPIC : INTRODUCTION OF VHDL.
1 The XMSF Profile Overlay to the FEDEP Dr. Katherine L. Morse, SAIC Mr. Robert Lutz, JHU APL
Jim McEachern Senior Technology Consultant ATIS July 8, 2015.
David Hatten Developer, UrbanCode 17 October 2013
Introduction To DBMS.
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
Software Project Configuration Management
2012 Spring Simulation Interoperability Workshop
Types for Programs and Proofs
Object-Oriented Analysis and Design
The Systems Engineering Context
TechStambha PMP Certification Training
Les Ginsberg Stefano Previdi Peter Psenak Martin Pilka
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Quality Management Systems – Requirements
An Overview of MPEG-21 Cory McKay.
CS 790M Project preparation (I)
Introduction to Software Testing
ELECTRONIC MAIL SECURITY
IEEE SCC41 PARs Date: Authors: August 2009 August 2009
ELECTRONIC MAIL SECURITY
System Modeling Assessment & Roadmap Joint OMG/INCOSE Working Group
Analysis models and design models
An Introduction to Software Architecture
Amendment 40 to ANNEX 15 Air Navigation Procedures for AIM Seminar
Verilog-AMS Integration with P1800 SV Standard
802.11ai Spec Development Process Update Proposal
Chapter 9 Architectural Design.
Metadata The metadata contains
Requirements Document
March 2013 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Comment Resolution Suggestions Date Submitted:
Matthew Sherman, BAE Systems
Design Yaodong Bi.
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec
CS 426 CS 791z Topics on Software Engineering
CS 426 CS 791z Topics on Software Engineering
BPSec: AD Review Comments and Responses
Ponder policy toolkit Jovana Balkoski, Rashid Mijumbi
Implementation Business Case
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Presentation transcript:

Based on Draft 3 and 3a work in progress John Shields Mentor Graphics, Inc. P1735 Standard Overview

Agenda JJS, P1735 Overview, March IEEE protection P1735 Goals P1735 V1 Recommendations P1735 V2 Recommendations P1735 Status and Plan Impact on 1800, 1076, other IP representations P1735 Future *Out of Scope for Today*

Out Of Scope For Today JJS, P1735 Overview, March Tutorial on conceptual model for IP protection Security risks Status of industry tool support How to build IEEE protection into HDL-based tools

IEEE Protection JJS, P1735 Overview, March Pragmas defined in SV and VHDL LRMs Describes encryption and decryption envelopes Promise of interoperability Policy free, forward looking markup of HDL representation of IP

IEEE Protection – Historical Reality JJS, P1735 Overview, March LRMs difficult to understand Intentional uncertainty to avoid export law conflicts Use case and some details not adequately defined for interoperability Early implementations only worked within vendor specific tool flows Stakeholders had a shopping list of enhancements

What is P1735? JJS, P1735 Overview, March IEEE P1735 —Recommended Practice standard —Covers Encryption and Rights Management for Electronic Design IP —Coordinating group for IP protection in IEEE Design Automation standards P1735 Goals —Achieve interoperability across heterogeneous tool chains —Define better use models —Add rights management mechanism for IP authors —Improve pragmas to match intent —Make IEEE protection more understandable to IP authors, IP users, and tool vendors

P1735 V1 Recommendations JJS, P1735 Overview, March Arose from industry effort to resolve issues with IEEE protection pragmas —Mutual customers demanded a correct solution —Existing implementations were technically correct, but wouldn’t work together V1 achieved basic interoperability across tool flows —Many vendors and tools have validated support today Available * in 2 forms —Early unpublished work in progress within the WG —Part of the final draft of P1735 Its the de-facto standard today

P1735 V1 Summary JJS, P1735 Overview, March Digital envelope use model Inline public key pragma clarifications Consensus on required support for specific encryption algorithms and encoding New version pragma for backward compatibility —allows tool specific implementations co-exist —Allows pragmas and use models to evolve

P1735 V2 Recommendations – First Look JJS, P1735 Overview, March Improved Key Management —Support of X.509 certificates for public key exchange New framework(set of pragmas) for rights management —admits both common and tool specific rights A licensing model for IP authors —Mechanism to grant per user access to IP —Secure protocol for tool interaction with external licensing proxy —Expressed as a condition on a right A small, conservative set of common rights —Error handling, visibility, decryption —Seamless transition from the default responsibility of all tools Better IP specific visibility control

Key Management JJS, P1735 Overview, March Use inline public key pragma (v1) —trust model (web of trust or peer to peer exchange, tool vendor to IP author) X.509 certificates (v2) —Additional defined trust model (CAs) possible —Mapped to pragma schema Encryption Tool Improvements possible —Key database and utilities

Rights Management Framework JJS, P1735 Overview, March Rights block —Plain text expression of rights for one or all tools —Tamper proof construction Basic rights syntax (simplified): `protect …,rights_block `protect control = `protect control = [,,, …] `protect …, rights_digest encoded encrypted rights block digest Reasonable composition rules for multiple declaration of the same right —with different conditions —in common and tool-specific blocks

Licensing JJS, P1735 Overview, March The ability to grant a right based on the availability of a license —Per user control over what can be done with an IP The licensing system contains the following components. 1. —License proxy is an executable provided by the IP author. It securely communicates with the EDA tool through a socket. 2. —License specification is several lines in a rights block, identifying the proxy, attributes, and a public key where the matching private key is hidden in the license proxy. 3. —License use is either a conditional rights assignment or an external right as described in Clause —Proxy communication is the details of secure message construction and communication between the license proxy and the EDA tool.

Common Rights JJS, P1735 Overview, March Means the same thing to all tools Default and delegated value of a right required — default - semantics when a common right is not specified — delegated – protect information but allow tool to operate for its intended purpose Common conditions —toolphase = compile | elaborate | run —activity = simulation | synthesis | analysis | layout —license Common rights (legal conditions not shown) —error_handling = delegated | nonames | srcrefs | plaintext —runtime_visibility = delegated | interface_names | all_names —decryption = delegated | true | false

Visibility Management JJS, P1735 Overview, March Existing semantics are clarified —Default expectation for all tools is a foundation —…but it’s not enough Existing visibility controls limitations are explained —Encryption envelopes and viewport pragma —Awkward, ill-defined, not portable Model fidelity trumps blind protection —It is invalid for a tool to modify the behavior of the model that the IP author wrote. Toolphases have basic visibility requirements —Compile and elaborate see everything —Nothing is required to be made visible externally Viewport pragma selectively exposes IP internals at runtime Common rights for error handling and general use cases

Boundaries Of First P1735 Standard JJS, P1735 Overview, March Visibility is still a complex area with open issues —Representation specific visibility control can’t be addressed in P1735 —P1735 intends to offer some guidance and principles Granularity of Encryption envelopes —Design unit granularity recommended for interoperability Relationship between disjoint protected envelopes —None! PLI —Large language centric analysis of information models Use of Obfuscation —Orthogonal external mechanism that has value —Other uses possible

Tasks/Schedule Considerations for P1735 JJS, P1735 Overview, March Internal WG draft comment period closes April 12 th D4 of draft in progress - inputs close April 15 th —Approval to ballot or revise further – April 29th D5 is possible Ballot group formation —Goal is end of April —We may postpone until after DAC IEEE ballot in July Sensitive to due process and financial constraints —Revision/Reballot due to negative ballot feedback —IEEE Revcom approval – august or december meetings —Technical editor funding – must be done with D5 by May —PAR expiration

P1735 Impact on 1800, P1076, and others JJS, P1735 Overview, March Assuming acceptance, DASC assumes content revision to other standards implied Scope of Update belongs to you —We were guided not to refactor the specification of encryption —Options –Incorporate some material by reference –Codify other aspects into LRM —Petition DASC to charter new PAR to refactor LRM and P1735 for future revision Some hard problems are still yours! —See earlier slides —They are intrinsically part of these standards, not P1735

P1735 Future JJS, P1735 Overview, March Foster education, outreach, promotion activity Study the need and timing of a follow-on PAR —Potential Considerations –refactoring - define a generic, complete pragma set with bindings to VHDL, SV, and potentially other representations –focus on encapsulation of IP representations –improve common rights –Address unique considerations in other tool flow components –Key management enhancements –Improving IP protection security – best practices for piracy prevention –Traceability – tagging and watermarking The Working Group serves at the pleasure of the DASC under IEEE rules —These comments about our future are our own expectations

© 2013 Mentor Graphics Corp. Company Confidential

Scope of P1735 JJS, P1735 Overview, March This standard specifies embeddable and encapsulating markup syntaxes for design IP encryption and rights management, together with recommendations for integration with design specification formats described in other standards. It also recommends use models for interoperable tool and hardware flows, which will include selecting encryption and encoding algorithms and encryption key management. The recommendation includes a description of the trust model assumed in the recommended use models. This standard does not specifically include any consideration of digitally encoded entertainment media. In the context of this document, the term IP will be used to mean Electronic Design Intellectual Property data.

Electronic Design Intellectual Property JJS, P1735 Overview, March Electronic Design Intellectual Property is a term used in the electronic design community. It refers to a reusable collection of design specifications which represent the behavior, properties, and/or representation of the design in various media. Examples of these collections include, but are not limited to: —A unit of electronic system design —A design verification and analysis scheme (e.g., test bench) —A netlist indicating elements and the interconnection thereof to implement a function —A set of fabrication instructions —A physical layout design or chip layout —A design intent specification The term is partially derived from the common practice for the collection to be considered the intellectual property of one party. Hardware and software descriptions are encompassed by this term.

Background Material - PAR JJS, P1735 Overview, March Purpose of Proposed Standard: The intent of this document is to enable design flows that provide interoperability between IP sources, tools, integrators, and users of the IP. There is currently no defined, independent standard for describing IP encryption markup for design information formats. Each design format which incorporates IP encryption describes their markup differently leading to confusing interpretation. Users of those standards also lack a recommended practice for inter-operable use of IP encryption.

Con’t JJS, P1735 Overview, March This document provides guidelines and recommended practice for use of IP protection markup syntax and key management to enable interoperable tool flows with IP and tools from a wide array of suppliers. It includes algorithm selection for encryption and encoding. This document specifies a generic set of embeddable markup syntax suitable for IP protection and rights management of arbitrary text files. These files represent potential inputs and outputs of EDA tools that would otherwise expose IP. The generic syntax of these directives may be suitably modified for a particular file format if there are syntactic conflicts and variations may be described in recommended practices.