The need for geofencing to help improve semiconductor IP security
At the heart of large-scale semiconductor projects are intellectual
property (IP) hardware or software components, essential for
implementing the design, but they can be hard to manage, trace, and keep
secure. In addition, global volatility, legal restrictions and
geographically distributed teams create extra pressure, with risks of IP
leakage, theft, fines, and loss of market reputation. The answer is to
adopt comprehensive IP geofencing to protect valuable technology without
slowing project velocity or hindering team collaboration.
BY SIMON BUTLER, PERFORCE
An organisation might have tens or even hundreds of thousands of these IPs interacting with each other in highly complex situations, factors which in themselves can make them hard to track and manage. Examples of IP are hardware components such as phased locked loops (PLLs), arithmetic logic units (ALUs), and analogue transceivers, all of which are used as functional building blocks in a System on Chip (SoC). Embedded software is another form of IP that should be managed in the same platform. These IPs exist in a rapidly changing, unpredictable global environment where one nation does not want its precious IP exposed to another country.
For instance, the US has ITAR and EAR, which regulate the export of defence articles and services. The European Union has Regulation (EU) 2021/821, which controls the export of dual-use items, such as software and technology, and which can be used for both civil and military purposes. Japan has the Foreign Exchange and Foreign Trade Act (FEFTA).
In October 2022, the US Department of Commerce’s Bureau of Industry and Security (BIS) announced sweeping revisions to its technology export controls. In the same year, the chief of AMSL — one of the leading European semiconductor organisations responsible for key manufacturing technology used worldwide — spoke publicly about the risks around IP leakage and the need for the industry to manage them more effectively.
Fines and firefighting
Fines for exporting restricted technology can quickly run into the $100,000s and even millions of dollars. In the most startling case, a large multinational semiconductor company recently paid $10 million in fines under these rules.
Not only are there financial penalties for semiconductor organisations who break these rules, but violations are also hard to manage, leading to firefighting instead of focusing on the project. And the situation constantly changes: what might be permissible one month could be restricted the next.
Furthermore, semiconductor firms typically have geographically dispersed workforces, pulling in resources from different teams and seeking out the best talent across the world. Employees who became used to remote working during the pandemic may now decide to experience living in another country for a while. People are starting to travel more. The multi-geographic nature of work is accelerating.
Plus, a complex and often overworked IT infrastructure of storage, data centres, and network connectivity underpins these teams. Add these factors together – a changing world, restrictions, the changing nature of work and technology systems — and it is easy to see how keeping track and securing technologies is complicated and cumbersome.
How IP leakage occurs
Before diving into how geofencing can help, it makes sense to understand how IP leakage occurs. The average SoC has more than 100 different IPs: some may be produced internally, others are provided by external sources. While malicious attacks are always a threat to take seriously, IP leakage can happen inadvertently. Here are a couple of scenarios.
First, imagine a semiconductor engineer travelling abroad to help a local team, carry out a demo, or have face-to-face meetings. During that trip, a problem arises with the project the engineer is working on back home and needs debugging. They build a local space and export all those components from a database in their own country to the one they are visiting.
Most of those IP components are fine, except for one, which is not even the one the engineer wants, is not visible and is not flagged as restricted. But by downloading this asset, the engineer has violated a restriction, and because they have logged in to the network at a remote site, they are allocated an IP address based on that geography. In turn, that information is logged and can be used to generate warnings or alarms. If not heeded, that action could lead to their employee being fined, loss of revenue and damaged brand reputation.
Here is another scenario. A company might be headquartered in the US but has multiple offices worldwide, and to make it easier for teams to share data, they build local IP caches. Now, those caches may have restrictions in place, for instance, ‘The Australian team does not have access to this IP’. However, the Australian team may see that it is available to their European counterparts, so they access the IP that way. While they have not directly exported the IP, the fact that they have acquired it is still a major problem.
This happens in real life, and it is not a criticism of those teams, who are often under considerable pressure to get a project completed and out the door. While IP leakage has to be managed, it must be done in a way that does not adversely impact people’s productivity. Users are generally unaware of the fine-grained details of the content they have accessed. The IP is opaque data, often just presented as a tarball (short for ‘tape archive’ — a set of files packaged together into a single file, then compressed using the gzip compression program).
Better IP management
So, how can all these challenges be addressed? The first step starts with the IP itself. For decades, semiconductor projects have been built as monolithic blocks, which worked well enough in the original context. Everything existed in one environment, and previous projects were copied to the new one because reuse always makes commercial sense. However, this approach makes traceability difficult: if the technology is suddenly restricted and there is some IP buried deep with no clear distinction to say that it should not be exported.
Therefore, the first step is to move from project-centric design to IP-centric design. In practice, this means that every unit or component is always maintained as a complete IP, whether built in-house or purchased from a third party, or reused for different projects. All these IPs can be stitched together in the project lifecycle management system into a hierarchical bill of materials (BoM), thus creating the projects. Moreover, the entire BoM can be reused as the starting point for another project while maintaining complete visibility of all the pieces.
Then, apply effective permissions management, with each IP having the correct view, read, write, or owner permissions. This is implemented via a permissions hub managed by a systems administrator, but in addition, each IP carries this information within itself.
Next, apply geofencing, which is additional metadata within the IP that dictates where it can be used. For example, a semiconductor company might operate in 30 locations, and geographies can be defined in different ways, such as ‘these are all our data centres in Ireland’ or ‘these are all our computer servers in India’.
This geographic distinction is determined by IP addresses, with IPv4 being the most logical since it is so universal, but other methods, such as IPv6, will be viable in the future. In effect, the onus is taken away from people having to work out restrictions because each IP determines whether it is allowed in a particular geography through its own metadata. Think of it as a passport accompanying that piece of IP everywhere, stopping it from entering a country when it does not have the appropriate visa.
Rather than extracting IP design data from the underlying data management system into a local workspace, embedding restrictions within the IP itself ensures that geographic protection overrules user permissions. So, even if someone usually has access to specific IP, this is blocked when travelling in a restricted region. Of course, situations change, so it is crucial that restrictions can be lifted. Again, by having that information embedded within the IP itself, the removal of a geographic ban is automatically populated wherever that IP is being used, without having to go into every single design project file to make that change.
Beyond helping to prevent IP leakage, this approach also prevents modifications to IP from becoming invisible or hard to trace because each piece of IP carries all relevant information within its metadata. Hence, when it comes to compliance and regulation processes, all the required details on how that IP was used, when, and where are easily accessible while reducing the manual burden on teams. Since workspaces are built IP-by-IP, companies can confidently guarantee that an IP never goes into a restricted geo.
Enabling collaboration
However, geofencing IP must not hinder the effective collaboration of globally distributed teams. The management of project configurations should be carried out predictably and securely. For instance, numerous projects engage external contractors, making it crucial to impose certain restrictions on these contributors. This is especially pertinent to their access to high-value intellectual properties (IPs) within the project.
Another concern is the potential for IP contamination, whereby engineers working on a specific IP might inadvertently gain access to similar third-party IPs available through the IP catalogue. Even well-intentioned engineers might find it challenging to avoid inference during the design process, possibly leading to unintentional replication of the third-party design. A further risk exists around sensitive subcomponents that should remain restricted at the source level, for example, the source code implementation for a process core or the specific implementation details of a leaf memory cell in a DRAM design. In such cases, to reduce the risk, an abstraction of the IP can be provided to the project, while certain aspects of its implementation are withheld from geofenced team members and other parties.
Better bill of materials (BoM) management
A more modern approach to managing BoMs can also enhance collaboration while still protecting IPs. In older workflows, distinct user groups were typically managed using separate BoMs, revealing only the relevant IP hierarchy to each group. However, this approach adds complexity to the process of releasing components and their corresponding hierarchies as they mature. Moreover, it necessitates the synchronisation of these disparate BoMs and their timely distribution to groups whenever updates to project releases are made.
A more effective solution involves using the same BoM across all project members, coupled with individualised permissions that filter the content delivered to each user’s workspace. Commonly referred to as “partial” workspaces, these setups enable users to execute releases and updates even in the absence of specific segments within the IP hierarchy.
That said, making well-informed decisions about which version of a missing subcomponent should be included in a release necessitates a certain level of sophistication in the IP management platform. During the initial workspace creation and subsequent workspaces updates, the user should be alerted to the fact that not all the IPs in the project hierarchy were synchronised over.
However, in many organisations, naming those IPs is another form of IP leakage, so just enough information should be provided to enable them to sanity-check their configuration without necessarily revealing specific components. With a single unified BoM across all IPs in the projects and contributors, there is a significantly reduced risk of inconsistencies and stale versions of the BoM being used by team members, while also increasing the robustness of the geofenced project environment.
So, is there an alternative to automated IP-led geofencing? Of course, traditional techniques could be used by throwing money and people at the problem, using spreadsheets and manual edits, but this could lead to over- or under-correction and introduce human error. Plus, as mentioned earlier, semiconductor design teams have enough workload and time pressures already, without adding IP geofencing to their daily routine. Securing semiconductor design is a multi-faceted challenge, but having an IP-centric approach that effectively makes the IP responsible for its own accessibility, should go a long way towards preventing geographic violations.
Reference
• https://www-ft-com.newman.richmond.edu/content/dfef74a7-bcc0-441b-95a5-380e212d9854
• https://www.engineersgarage.com/semiconductor-ip-geofencing
