IP protection under OASIS
Companies and mask shops already have plans and policies to secure the storage and transmission of sensitive layout VLSI data. These include confidentiality and non-disclosure agreements, and encryption. However, traditional VLSI file formats such as GDSII never popularized the type of constructs that facilitate intellectual property (IP) protection. The OASIS format does have these constructs.
The OASIS method, partial selective encryption (PSE), accurately matches security needs while overcoming the difficulties with total file encryption. The new method uses blocklevel compression defined within OASIS.
PSE allows partial encryption and concealment of specific layout components, and contains a selective access control scheme. Because the scope of the method exists entirely within the context of the OASIS standard, PSE-encrypted files are interchangeable with unencrypted files in any OASIS-compliant reader. Furthermore, the presence of encrypted components is automatically transparent to users without access.Within a consistent security implementation, the presence or absences of encrypted components remains invisible or visible to an adversary. The process contributes negligibly to file processing time and provides a significant advantage in file-size reduction over total encryption.
Modern VLSI encryption
In the absence of improved format-level mechanisms for encryption, the industry has used external encryption methods. To encrypt a design data file, users run standard external encryption software across the entire contents, a process referred to as total encryption. This does not meet the requirements of corporate security plans, which may suggest varying levels of access to design file components for different partners. It is also wasteful. The growth in file size inherent in padding a file for strong encryption adds bloat to already excessively large layout files.
The OASIS format
The OASIS standard was developed to head off two rapidly approaching bottlenecks in the GDSII:
- An explosion in the size of GDSII stream design and mask layout file sizes.
- The need to store numbers larger than 232 for high precision descriptions at the nanometer scale.
By the release of OASIS in 2003, GDSII designs had already exceeded 1TB. The transmission and manipulation of such files was difficult, even before accounting for total encryption. The OASIS standard adequately resolved these bottlenecks.
Partial selective encryption
An OASIS file stores a layout description as a list of records in ASCII format. As the fundamental data divisions of an OASIS file, records contain information describing all cells, hierarchy, and geometry in a file. These assume one of several types, such as cell, polygon or text, which are nested within other records to define implicitly the hierarchy of a layout. A higher-level record might describe collections of cells, while contained within it are simpler records describing collections of trapezoids, circles, or paths inside a cell.Multiple options exist for reducing the space needed to describe cell geometry, such as the repetition property, which indicates regularly or irregularly spaced instances of the same object throughout a layout.
In keeping with the file-size reduction of the OASIS standard, its CBLOCK record introduced a method to facilitate compression. CBLOCKs declare that the contents following the declaration are treated as compressed data and not ASCII. Therefore, the CBLOCK record compresses user-specified specific cells, polygons (or entire layers or hierarchy components).
The OASIS standard is algorithm- and software-independent, so the CBLOCK record accommodates several compression schemes. We designed this property to reserve the value explicitly. OASIS reserves the value COMP-type = 0 for the DEFLATE Compressed Data Format. One can use any alternative CBLOCK compression scheme at higher values, so long as it complies with RFC 1951. For example, ZLIB compression software version 1.1.4 provides an alternative to DEFLATE.Most commonly, OASIS users denote compressed ZLIB files as COMP-Type 0. As the standard evolves, it is likely to be updated to reserve this value for ZLIB, and may eventually include other compression methods.
Encryption via COMP-Type adjustment
Critically for encryption, OASIS is generous on admitting compression schemes. So long as a method is compliant with RFC1951, the standard permits it. This allows the use of any RFC1951 arbitrary encoding method (and not simply zero, which actually compresses a file). In other words, substituting a scheme, which gives an encrypted encoding of a cell instead of a compressed encoding, will not conflict with the requirements of the OASIS format.
PSE works by permitting the selective encryption of data within a CBLOCK record.We selected an unused value for a COMP-type to associate with the user’s preferred encryption method. Thus, this method of encryption replaces compression methods when preparing the encrypted CBLOCK record, with “uncomp-byte-count” and “comp-byte-count” referring to the unencrypted and encrypted byte-counts. In other words, the PSE-CBLOCK format will be:
’34’ enc-type decrypt-byte-count encrypt-byte-count encrypted-bytes
Essentially, CBLOCK-based PSE replaces CBLOCK compression methods at the cell level, at the top of a hierarchy or at the level of individual polygons.
OASIS standards compliance
The CBLOCK PSE method is syntactically equivalent to a normal CBLOCK compression record, but is it OASIS compliant? OASIS readers may complain when finding an unknown COMP Type number, but one compliant to the standard will not crash when it encounters syntactically valid CBLOCK descriptions that have unfamiliar COMP-types.
A compliant OASIS reader should read these CBLOCKS and pass over them, since it does not recognize the compression algorithm. Accordingly, the presence of encrypted CBLOCKS is transparent to the reader; a reader without the key will not read the content of these records beyond ensuring syntactic validity.
Figure 1. The un-encrypted or “plain text” layout is on the left side. In the total encryption method, shown top right, one encrypts the whole file. No information can be extracted from this locked database. In partial selective encryption (PSE), shown bottom right, we encrypt facets of the layout individually.
Since the standard explicitly allows for multiple compression schemes within a single file, unencrypted CBLOCK records can unobtrusively coexist with encrypted CBLOCK records.Moreover, the user can compress an individually encrypted CBLOCK record. Although the standard does not permit nesting of CBLOCK records within other CBLOCKs, it is a simple matter to take the composition of a compression operation and an encryption operation, and implement the pair as a single transform.
User experience
Design file owner
We define a facet as a unique and orthogonal view into some component of the layout. A facet can present any amount of information about the design file, ranging from total access without individual polygons or cells, to all but a few layers and individual levels of hierarchy, to total access. A facet can present information about a collection of components even if it is an encrypted collection, such as the bounding-box data. A facet can incorporate both encrypted and unencrypted meta-information about components. The design file owner (customer) begins by defining a number of accessible facets. For example, a vendor needing access to bounding box data for intersection purposes should get access to only meta-information pertaining to cell geometry along with other relevant nonproprietary information. A second example can be a vendor whose product generates errors within a given cell. They should have access to the particular cell along with any relevant nonproprietary information.
Prior to writing or modifying the OASIS file, the designer chooses the facets they seek to encrypt. An external program generates the encryption keys for each. An intelligent OASIS writer can link these processes so that the interface for the designer is seamless. The OASIS writer will receive a set of commands as follows:
- BeginCompression enc-type enc-key
- record-name record-data
- EndCompression
The syntax for communicating encryption to the OASIS writer is identical to that used to indicate compression of files. The encryption-enabled OASIS writer will use the encryption program denoted by the integer enc-type and the key denoted by the string enc-key to encrypt the record.
The resulting OASIS file will contain a list of encrypted CBLOCKs in standard form in the appropriate locations. For instance, these entries might read:
’34’ enc-type 4000 1000 encrypted-block
Collaborator
For a party lacking access keys, the OASIS parser will read over the syntactically correct CBLOCKS and simply not decompress them. When viewing within an OASIS viewer or manipulated in an OASIS EDA or CAD tool, encrypted blocks simply do not appear. Converting encrypted blocks to decrypted records is easy for parties with access. An encryption-enabled OASIS reader will simply use the decryption scheme associated with the given enc-type.
Security strength
For OASIS-based PSE to achieve common use in the industry, it must demonstrate theoretical security strength at least equal to that of total encryption, in addition to the practical advantages it presents in terms of file size.
Any group without permission and keys should be unable to access any information about the encrypted layout components.
Because partial selective encryption is algorithm-agnostic, the user can use an encryption method of arbitrary strength.We have tested 1024-bit RSA public/private keys and Blowfish encryption.
These are some of the strongest encryption methods available. OASIS PSE provides security equivalent to the strength of the encryption algorithm.
About the author
Thomas Grebinski is CEO of Yotta Data Sciences.
