Get ONMINE

Stay Ahead, Stay ONMINE

Algorithm Protection in the Context of Federated Learning 

While working at a biotech company, we aim to advance ML & AI Algorithms to enable, for example, brain lesion segmentation to be executed at the hospital/clinic location where patient data resides, so it is processed in a secure manner. This, in essence, is guaranteed by federated learning mechanisms, which we have adopted in numerous real-world hospital settings. However, when an algorithm is already considered as a company asset, we also need means that protect not only sensitive data, but also secure algorithms in a heterogeneous federated environment. Fig.1 High-level workflow and attack surface. Image by author Most algorithms are assumed to be encapsulated within docker-compatible containers, allowing them to use different libraries and runtimes independently. It is assumed that there is a 3rd party IT administrator who will aim to secure patients’ data and lock the deployment environment, making it inaccessible for algorithm providers. This perspective describes different mechanisms intended to package and protect containerized workloads against theft of intellectual property by a local system administrator.  To ensure a comprehensive approach, we will address protection measures across three critical layers: Algorithm code protection: Measures to secure algorithm code, preventing unauthorized access or reverse engineering. Runtime environment: Evaluates risks of administrators accessing confidential data within a containerized system. Deployment environment: Infrastructure safeguards against unauthorized system administrator access. Fig.2 Different layers of protection. Image by author Methodology After analysis of risks, we have identified two protection measures categories: Intellectual property theft and unauthorized distribution: preventing administrator users from accessing, copying, executing the algorithm.  Reverse engineering risk reduction: blocking administrator users from analyzing code to uncover and claim ownership. While understanding the subjectivity of this assessment, we have considered both qualitative and quantitative characteristics of all mechanisms. Qualitative assessment Categories mentioned were considered when selecting suitable solution and are considered in summary: Hardware dependency: potential lock-in and scalability challenges in federated systems. Software dependency: reflects maturity and long-term stability Hardware and Software dependency: measures setup complexity, deployment and maintenance effort Cloud dependency: risks of lock-in with a single cloud hypervisor Hospital environment: evaluates technology maturity and requirements heterogeneous hardware setups. Cost: covers for dedicated hardware, implementation and maintenance Quantitative assessment Subjective risk reduction quantitative assessment description: Considering the above methodology and assessment criteria, we came up with a list of mechanisms that have the potential to guarantee the objective.  Confidential containers Confidential Containers (CoCo) is an emerging CNCF technology that aims to deliver confidential runtime environments that will run CPU and GPU workloads while protecting the algorithm code and data from the hosting company. CoCo supports multiple TEE, including Intel TDX/SGX and AMD SEV hardware technologies, including extensions of NVidia GPU operators, that use hardware-backed protection of code and data during its execution, preventing scenarios in which a determined and skillful local administrator uses a local debugger to dump the contents of the container memory and has access to both the algorithm and data being processed.  Trust is built using cryptographic attestation of runtime environment and code that is executed. It makes sure the code is not tempered with nor read by remote admin. This appears to be a perfect fit for our problem, as the remote data site admin would not be able to access the algorithm code. Unfortunately, the current state of the CoCo software stack, despite continuous efforts, still suffers from security gaps that enable the malicious administrators to issue attestation for themselves and effectively bypass all the other protection mechanisms, rendering all of them effectively useless. Each time the technology gets closer to practical production readiness, a new fundamental security issue is discovered that needs to be addressed. It is worth noting that this community is fairly transparent in communicating gaps.  The often and rightfully recognized additional complexity introduced by TEEs and CoCo (specialized hardware, configuration burden, runtime overhead due to encryption) would be justifiable if the technology delivered on its promise of code protection. While TEE seems to be well adopted, CoCo is close but not there yet and based on our experiences the horizon keeps on moving, as new fundamental vulnerabilities are discovered and need to be addressed. In other words, if we had production-ready CoCo, it would have been a solution to our problem.  Host-based container image encryption at rest (protection at rest and in transit) This strategy is based on end-to-end protection of container images containing the algorithm. It protects the source code of the algorithm at rest and in transit but does not protect it at runtime, as the container needs to be decrypted prior to the execution. The malicious administrator at the site has direct or indirect access to the decryption key, so he can read container contents just after it is decrypted for the execution time.  Another attack scenario is to attach a debugger to the running container image. So host-based container image encryption at rest makes it harder to steal the algorithm from a storage device and in transit due to encryption, but moderately skilled administrators can decrypt and expose the algorithm. In our opinion, the increased practical effort of decrypting the algorithm (time, effort, skillset, infrastructure) from the container by the administrator who has access to the decryption key is too low to be considered as a valid algorithm protection mechanism. Prebaked custom virtual machine In this scenario the algorithm owner is delivering an encrypted virtual machine. The key can be added at boot time from the keyboard by someone else than admin (required at each reboot), from external storage (USB Key, very vulnerable, as anyone with physical access can attach the key storage), or using a remote SSH session (using Dropbear for instance) without allowing local admin to unlock the bootloader and disk. Effective and established technologies such as LUKS can be used to fully encrypt local VM filesystems including bootloader. However, even if the remote key is provided using a boot-level tiny SSH session by someone other than a malicious admin, the runtime is exposed to a hypervisor-level debugger attack, as after boot, the VM memory is decrypted and can be scanned for code and data. Still, this solution, especially with remotely provided keys by the algorithm owner, provides significantly increased algorithm code protection compared to encrypted containers because an attack requires more skills and determination than just decrypting the container image using a decryption key.  To prevent memory dump analysis, we considered deploying a prebaked host machine with ssh possessed keys at boot time, this removes any hypervisor level access to memory. As a side note, there are methods to freeze physical memory modules to delay loss of data. Distroless container images Distroless container images are reducing the number of layers and components to a minimum required to run the algorithm. The attack surface is greatly reduced, as there are fewer components prone to vulnerabilities and known attacks. They are also lighter in terms of storage, network transmission, and latency. However, despite these improvements, the algorithm code is not protected at all.  Distroless containers are recommended as more secure containers but not the containers that protect the algorithm, as the algorithm is there, container image can be easily mounted and algorithm can be stolen without a significant effort. Being distroless does not address our goal of protecting the algorithm code. Compiled algorithm Most machine learning algorithms are written in Python. This interpreted language makes it really easy not only to execute the algorithm code on other machines and in other environments but also to access source code and be able to modify the algorithm. The potential scenario even enables the party that steals the algorithm code to modify it, let’s say 30% or more of the source code, and claim it’s no longer the original algorithm, and could even make a legal action much harder to provide evidence of intellectual property infringement. Compiled languages, such as C, C++, Rust, when combined with strong compiler optimization (-O3 in the case of C, linker-time optimizations), make the source code not only unavailable as such, but also much harder to reverse engineer source code.  Compiler optimizations introduce significant control flow changes, mathematical operations substitutions, function inlining, code restructuring, and difficult stack tracing. This makes it much harder to reverse engineer the code, making it a practically infeasible option in some scenarios, thus it can be considered as a way to increase the cost of reverse engineering attack by orders of magnitude compared to plain Python code. There’s an increased complexity and skill gap, as most of the algorithms are written in Python and would have to be converted to C, C++ or Rust. This option does increase the cost of further development of the algorithm and even modifying it to make a claim of its ownership but it does not prevent the algorithm from being executed outside of the agreed contractual scope. Code obfuscation The established technique of making the code much less readable, harder to understand and develop further can be used to make algorithm evolutions much harder. Unfortunately, it does not prevent the algorithm from being executed outside of contractual scope. Also, the de-obfuscation technologies are getting much better, thanks to advanced language models, lowering the practical effectiveness of code obfuscation. Code obfuscation does increase the practical cost of algorithm reverse engineering, so it’s worth considering as an option combined with other options (for instance, with compiled code and custom VMs). Homomorphic Encryption as code protection mechanism Homomorphic Encryption (HE) is a promised technology aimed at protecting the data, very interesting from secure aggregation strategies of partial results in Federated Learning and analytics scenarios.  The aggregation party (with limited trust) can only process encrypted data and perform encrypted aggregations, then it can decrypt aggregated results without being able to decrypt any individual data. Practical applications of HE are limited due to its complexity, performance hits, limited number of supported operations, there’s observable progress (including GPU acceleration for HE) but still it’s a niche and emerging data protection technique. From an algorithm protection goal perspective, HE is not designed, nor can be made to protect the algorithm. So it’s not an algorithm protection mechanism at all. Conclusions Fig.3 Risk reduction scores, Image by author In essence, we described and assessed strategies and technologies to protect algorithm IP and sensitive data in the context of deploying Medical Algorithms and running them in potentially untrusted environments, such as hospitals. What’s visible, the most promising technologies are those that provide a degree of hardware isolation. However those make an algorithm provider completely dependent on the runtime it will be deployed. While compilation and obfuscation do not mitigate completely the risk of intellectual property theft, especially even basic LLM seem to be helpful, those methods, especially when combined, make algorithms very difficult, thus expensive, to use and modify the code. Which would already provide a degree of security. Prebaked host/virtual machines are the most common and adopted methods, extended with features like full disk encryption with keys acquired during boot via SSH, which could make it fairly difficult for local admin to access any data. However, especially pre-baked machines could cause certain compliance concerns at the hospital, and this needs to be assessed prior to establishing a federated network.  Key Hardware and Software vendors(Intel, AMD, NVIDIA, Microsoft, RedHat) recognized significant demand and continue to evolve, which gives a promise that training IP-protected algorithms in a federated manner, without disclosing patients’ data, will soon be within reach. However, hardware-supported methods are very sensitive to hospital internal infrastructure, which by nature is quite heterogeneous. Therefore, containerisation provides some promise of portability. Considering this, Confidential Containers technology seems to be a very tempting promise provided by collaborators, while it’s still not fullyproduction-readyy. Certainly combining above mechanisms, code, runtime and infrastructure environment supplemented with proper legal framework decrease residual risks, however no solution provides absolute protection particularly against determined adversaries with privileged access – the combined effect of these measures creates substantial barriers to intellectual property theft.  We deeply appreciate and value feedback from the community helping to further steer future efforts to develop sustainable, secure and effective methods for accelerating AI development and deployment. Together, we can tackle these challenges and achieve groundbreaking progress, ensuring robust security and compliance in various contexts.  Contributions: The author would like to thank Jacek Chmiel, Peter Fernana Richie, Vitor Gouveia and the Federated Open Science team at Roche for brainstorming, pragmatic solution-oriented thinking, and contributions. Link & Resources Intel Confidential Containers Guide  Nvidia blog describing integration with CoCo Confidential Containers Github & Kata Agent Policies Commercial Vendors: Edgeless systems contrast, Redhat & Azure Remote Unlock of LUKS encrypted disk A perfect match to elevate privacy-enhancing healthcare analytics Differential Privacy and Federated Learning for Medical Data

While working at a biotech company, we aim to advance ML & AI Algorithms to enable, for example, brain lesion segmentation to be executed at the hospital/clinic location where patient data resides, so it is processed in a secure manner. This, in essence, is guaranteed by federated learning mechanisms, which we have adopted in numerous real-world hospital settings. However, when an algorithm is already considered as a company asset, we also need means that protect not only sensitive data, but also secure algorithms in a heterogeneous federated environment.

Fig.1 High-level workflow and attack surface. Image by author

Most algorithms are assumed to be encapsulated within docker-compatible containers, allowing them to use different libraries and runtimes independently. It is assumed that there is a 3rd party IT administrator who will aim to secure patients’ data and lock the deployment environment, making it inaccessible for algorithm providers. This perspective describes different mechanisms intended to package and protect containerized workloads against theft of intellectual property by a local system administrator. 

To ensure a comprehensive approach, we will address protection measures across three critical layers:

  • Algorithm code protection: Measures to secure algorithm code, preventing unauthorized access or reverse engineering.
  • Runtime environment: Evaluates risks of administrators accessing confidential data within a containerized system.
  • Deployment environment: Infrastructure safeguards against unauthorized system administrator access.
Fig.2 Different layers of protection. Image by author

Methodology

After analysis of risks, we have identified two protection measures categories:

  • Intellectual property theft and unauthorized distribution: preventing administrator users from accessing, copying, executing the algorithm. 
  • Reverse engineering risk reduction: blocking administrator users from analyzing code to uncover and claim ownership.

While understanding the subjectivity of this assessment, we have considered both qualitative and quantitative characteristics of all mechanisms.

Qualitative assessment

Categories mentioned were considered when selecting suitable solution and are considered in summary:

  • Hardware dependency: potential lock-in and scalability challenges in federated systems.
  • Software dependency: reflects maturity and long-term stability
  • Hardware and Software dependency: measures setup complexity, deployment and maintenance effort
  • Cloud dependency: risks of lock-in with a single cloud hypervisor
  • Hospital environment: evaluates technology maturity and requirements heterogeneous hardware setups.
  • Cost: covers for dedicated hardware, implementation and maintenance

Quantitative assessment

Subjective risk reduction quantitative assessment description:

Considering the above methodology and assessment criteria, we came up with a list of mechanisms that have the potential to guarantee the objective. 

Confidential containers

Confidential Containers (CoCo) is an emerging CNCF technology that aims to deliver confidential runtime environments that will run CPU and GPU workloads while protecting the algorithm code and data from the hosting company.

CoCo supports multiple TEE, including Intel TDX/SGX and AMD SEV hardware technologies, including extensions of NVidia GPU operators, that use hardware-backed protection of code and data during its execution, preventing scenarios in which a determined and skillful local administrator uses a local debugger to dump the contents of the container memory and has access to both the algorithm and data being processed. 

Trust is built using cryptographic attestation of runtime environment and code that is executed. It makes sure the code is not tempered with nor read by remote admin.

This appears to be a perfect fit for our problem, as the remote data site admin would not be able to access the algorithm code. Unfortunately, the current state of the CoCo software stack, despite continuous efforts, still suffers from security gaps that enable the malicious administrators to issue attestation for themselves and effectively bypass all the other protection mechanisms, rendering all of them effectively useless. Each time the technology gets closer to practical production readiness, a new fundamental security issue is discovered that needs to be addressed. It is worth noting that this community is fairly transparent in communicating gaps. 

The often and rightfully recognized additional complexity introduced by TEEs and CoCo (specialized hardware, configuration burden, runtime overhead due to encryption) would be justifiable if the technology delivered on its promise of code protection. While TEE seems to be well adopted, CoCo is close but not there yet and based on our experiences the horizon keeps on moving, as new fundamental vulnerabilities are discovered and need to be addressed.

In other words, if we had production-ready CoCo, it would have been a solution to our problem. 

Host-based container image encryption at rest (protection at rest and in transit)

This strategy is based on end-to-end protection of container images containing the algorithm.

It protects the source code of the algorithm at rest and in transit but does not protect it at runtime, as the container needs to be decrypted prior to the execution.

The malicious administrator at the site has direct or indirect access to the decryption key, so he can read container contents just after it is decrypted for the execution time. 

Another attack scenario is to attach a debugger to the running container image.

So host-based container image encryption at rest makes it harder to steal the algorithm from a storage device and in transit due to encryption, but moderately skilled administrators can decrypt and expose the algorithm.

In our opinion, the increased practical effort of decrypting the algorithm (time, effort, skillset, infrastructure) from the container by the administrator who has access to the decryption key is too low to be considered as a valid algorithm protection mechanism.

Prebaked custom virtual machine

In this scenario the algorithm owner is delivering an encrypted virtual machine.

The key can be added at boot time from the keyboard by someone else than admin (required at each reboot), from external storage (USB Key, very vulnerable, as anyone with physical access can attach the key storage), or using a remote SSH session (using Dropbear for instance) without allowing local admin to unlock the bootloader and disk.

Effective and established technologies such as LUKS can be used to fully encrypt local VM filesystems including bootloader.

However, even if the remote key is provided using a boot-level tiny SSH session by someone other than a malicious admin, the runtime is exposed to a hypervisor-level debugger attack, as after boot, the VM memory is decrypted and can be scanned for code and data.

Still, this solution, especially with remotely provided keys by the algorithm owner, provides significantly increased algorithm code protection compared to encrypted containers because an attack requires more skills and determination than just decrypting the container image using a decryption key. 

To prevent memory dump analysis, we considered deploying a prebaked host machine with ssh possessed keys at boot time, this removes any hypervisor level access to memory. As a side note, there are methods to freeze physical memory modules to delay loss of data.

Distroless container images

Distroless container images are reducing the number of layers and components to a minimum required to run the algorithm.

The attack surface is greatly reduced, as there are fewer components prone to vulnerabilities and known attacks. They are also lighter in terms of storage, network transmission, and latency.

However, despite these improvements, the algorithm code is not protected at all. 

Distroless containers are recommended as more secure containers but not the containers that protect the algorithm, as the algorithm is there, container image can be easily mounted and algorithm can be stolen without a significant effort.

Being distroless does not address our goal of protecting the algorithm code.

Compiled algorithm

Most machine learning algorithms are written in Python. This interpreted language makes it really easy not only to execute the algorithm code on other machines and in other environments but also to access source code and be able to modify the algorithm.

The potential scenario even enables the party that steals the algorithm code to modify it, let’s say 30% or more of the source code, and claim it’s no longer the original algorithm, and could even make a legal action much harder to provide evidence of intellectual property infringement.

Compiled languages, such as C, C++, Rust, when combined with strong compiler optimization (-O3 in the case of C, linker-time optimizations), make the source code not only unavailable as such, but also much harder to reverse engineer source code. 

Compiler optimizations introduce significant control flow changes, mathematical operations substitutions, function inlining, code restructuring, and difficult stack tracing.

This makes it much harder to reverse engineer the code, making it a practically infeasible option in some scenarios, thus it can be considered as a way to increase the cost of reverse engineering attack by orders of magnitude compared to plain Python code.

There’s an increased complexity and skill gap, as most of the algorithms are written in Python and would have to be converted to C, C++ or Rust.

This option does increase the cost of further development of the algorithm and even modifying it to make a claim of its ownership but it does not prevent the algorithm from being executed outside of the agreed contractual scope.

Code obfuscation

The established technique of making the code much less readable, harder to understand and develop further can be used to make algorithm evolutions much harder.

Unfortunately, it does not prevent the algorithm from being executed outside of contractual scope.

Also, the de-obfuscation technologies are getting much better, thanks to advanced language models, lowering the practical effectiveness of code obfuscation.

Code obfuscation does increase the practical cost of algorithm reverse engineering, so it’s worth considering as an option combined with other options (for instance, with compiled code and custom VMs).

Homomorphic Encryption as code protection mechanism

Homomorphic Encryption (HE) is a promised technology aimed at protecting the data, very interesting from secure aggregation strategies of partial results in Federated Learning and analytics scenarios. 

The aggregation party (with limited trust) can only process encrypted data and perform encrypted aggregations, then it can decrypt aggregated results without being able to decrypt any individual data.

Practical applications of HE are limited due to its complexity, performance hits, limited number of supported operations, there’s observable progress (including GPU acceleration for HE) but still it’s a niche and emerging data protection technique.

From an algorithm protection goal perspective, HE is not designed, nor can be made to protect the algorithm. So it’s not an algorithm protection mechanism at all.

Conclusions

Fig.3 Risk reduction scores, Image by author

In essence, we described and assessed strategies and technologies to protect algorithm IP and sensitive data in the context of deploying Medical Algorithms and running them in potentially untrusted environments, such as hospitals.

What’s visible, the most promising technologies are those that provide a degree of hardware isolation. However those make an algorithm provider completely dependent on the runtime it will be deployed. While compilation and obfuscation do not mitigate completely the risk of intellectual property theft, especially even basic LLM seem to be helpful, those methods, especially when combined, make algorithms very difficult, thus expensive, to use and modify the code. Which would already provide a degree of security.

Prebaked host/virtual machines are the most common and adopted methods, extended with features like full disk encryption with keys acquired during boot via SSH, which could make it fairly difficult for local admin to access any data. However, especially pre-baked machines could cause certain compliance concerns at the hospital, and this needs to be assessed prior to establishing a federated network. 

Key Hardware and Software vendors(Intel, AMD, NVIDIA, Microsoft, RedHat) recognized significant demand and continue to evolve, which gives a promise that training IP-protected algorithms in a federated manner, without disclosing patients’ data, will soon be within reach. However, hardware-supported methods are very sensitive to hospital internal infrastructure, which by nature is quite heterogeneous. Therefore, containerisation provides some promise of portability. Considering this, Confidential Containers technology seems to be a very tempting promise provided by collaborators, while it’s still not fullyproduction-readyy.

Certainly combining above mechanisms, code, runtime and infrastructure environment supplemented with proper legal framework decrease residual risks, however no solution provides absolute protection particularly against determined adversaries with privileged access – the combined effect of these measures creates substantial barriers to intellectual property theft. 

We deeply appreciate and value feedback from the community helping to further steer future efforts to develop sustainable, secure and effective methods for accelerating AI development and deployment. Together, we can tackle these challenges and achieve groundbreaking progress, ensuring robust security and compliance in various contexts. 

Contributions: The author would like to thank Jacek Chmiel, Peter Fernana Richie, Vitor Gouveia and the Federated Open Science team at Roche for brainstorming, pragmatic solution-oriented thinking, and contributions.

Link & Resources

Intel Confidential Containers Guide 

Nvidia blog describing integration with CoCo Confidential Containers Github & Kata Agent Policies

Commercial Vendors: Edgeless systems contrast, Redhat & Azure

Remote Unlock of LUKS encrypted disk

A perfect match to elevate privacy-enhancing healthcare analytics

Differential Privacy and Federated Learning for Medical Data

Shape
Shape
Stay Ahead

Explore More Insights

More Articles

Stay ahead with more perspectives on cutting-edge power, infrastructure, energy,  bitcoin and AI solutions. Explore these articles to uncover strategies and insights shaping the future of industries.

Shape

Nutanix expands beyond HCI

The Pure Storage integration will also be supported within Cisco’s FlashStack offering, creating a “FlashStack with Nutanix” solution with storage provided by Pure, networking capabilities as well as UCS servers from Cisco, and then the common Nutanix Cloud Platform. Cloud Native AOS: Breaking free from hypervisors Another sharp departure from

Read More »

IBM introduces new generation of LinuxOne AI mainframe

In addition to generative AI applications, new multiple model AI approaches are engineered to enhance prediction and accuracy in many industry use cases like advanced fraud detection, image processing and retail automation, according to IBM. LinuxONE Emperor 5 also comes with advanced security features specifically designed for the AI threat

Read More »

Business leaders and SNP call on Starmer to visit Aberdeen amid North Sea job losses

Aberdeen business leaders and the SNP are calling on the Prime Minister to visit the north-east of Scotland as they blamed Labour policies for yet more job losses in the oil and gas sector. On Wednesday, Harbour Energy announced that it would cut 250 jobs from its onshore operations, accounting for a 25% reduction in headcount. The UK’s largest producer of oil and gas has claimed that the hostile fiscal policy facing oil and gas businesses prompted the decision as it slows investment in the country, opting to allocate funds overseas. On the day of this announcement, Aberdeen South MP and SNP Westminster leader Stephen Flynn brought the news to the attention of prime minister Sir Keir Starmer. © BloombergEmissions from chimneys at the British Steel Ltd. plant in Scunthorpe, UK. He asked Starmer to “explain to my constituents why he is willing to move heaven and earth to save jobs in Scunthorpe while destroying jobs in Scotland.” The SNP leader was referring to the government’s recent move to nationalise British Steel. The UK government took control of the British steel company from its Chinese owner, Jingye Group, after losses from its steelmaking operations forced it to the brink. Now the SNP MP, alongside his colleagues in Westminster and Holyrood, has written to the Labour Party leader, inviting him to see the impacts his government’s energy policy is having on Aberdeen and its people. “We are writing to you as the local MPs and MSPs for Aberdeen, to invite you to urgently visit Aberdeen to meet with local representatives, businesses, trade unions and workers to hear about the damaging impact that Labour government policies are having on Scottish energy jobs – and to discuss the urgent investment needed to protect jobs and deliver prosperity,” the letter reads. ‘Haemorrhaging investment in

Read More »

Oil Gains 3% as Trade Hopes Rise

Oil rose as President Donald Trump announced a trade framework with the UK, spurring some optimism about deals to come. West Texas Intermediate climbed 3.2% to approach $60 a barrel. Trump said the UK would fast-track US items through its customs process and reduce barriers on billions of dollars of agricultural, chemical, energy and industrial exports, including ethanol. Notably, the terms are limited in scope and a 10% baseline tariff remains. The British deal is raising investors’ confidence that agreements can be reached in the more complicated trade talks that lie ahead, specifically negotiations between US and Chinese officials kicking off this weekend. Trump said that the 145% levy against China, the world’s largest crude-importer, could be lowered if talks go well. “The real driver of risk assets today appears to be renewed optimism around progress in the US–China trade talks,” said Rebecca Babin, a senior energy trader at CIBC Private Wealth Group. “It’s also worth noting that sentiment toward crude remains overwhelmingly bearish.” Crude has slid since Trump took office on concerns that his global trade war will dent economic growth and slow energy demand. Adding to the bearishness, OPEC+ has decided to revive idled output faster than expected. Already, the drop in oil prices is spurring American shale producers to cut spending in the Permian Basin. Still, small pockets of bullishness are visible in the options market. There was active trading of Brent $95 September call options, which profit when futures rise. The US on Thursday sanctioned a third Chinese “teapot” oil refinery and various other entities associated with Iran, days ahead of a fourth round of nuclear talks between Washington and Tehran. The failure of the negotiations could push Brent up toward $70 a barrel, Citigroup analysts including Eric Lee said in a note. In the US,

Read More »

Indian LNG Buyers Embrace USA Benchmark to Balance Volatility

Indian liquefied natural gas importers have signed a flurry of long-term purchase agreements linked to the US price benchmark, the latest effort by the nation’s buyers to protect themselves from volatile markets. State-owned companies have signed at least four contracts since December, totaling nearly 11 million tons per year, priced to the Henry Hub index, according to the executives familiar with the deals. Until now, most of India’s long-term contracts have been linked to crude oil, the traditional way to price LNG deals. Pricing the fuel to the Henry Hub index doesn’t necessarily mean that the fuel will come from the US, rather it is a move to hedge risk.  India’s consumers — from power plants to petrochemical facilities — are highly price-sensitive as gas competes head-to-head with cheaper and dirtier alternatives. Companies that relied on the spot market or oil-linked contracts have periodically been forced to cut back purchases due to price spikes. US gas futures have also been relatively less volatile and more liquid than the Asian spot benchmark, the Japan-Korea Marker. “The last ten year average shows that there have been periods during winter months JKM benchmark surged beyond imagination, while Henry Hub prices saw proportionally smaller growth,” Bharat Petroelum Corp Ltd’s Director Finance V.R.K. Gupta said. BPCL in February signed a deal with ADNOC Trading for 2.5 million tons of LNG for five years. The Mumbai-based refiner will evaluate the performance of the deal and may sign more such contracts, Gupta said.  Indian Oil Corp. last week signed a deal with Trafigura for 2.5 million tons, or 27 cargoes, spread over five years, with supplies starting the middle of this year. The recent deals have been signed at a 115% link to Henry Hub plus $5 to $6 per million British thermal units. The supply is

Read More »

PJM, utilities urge FERC to dismiss call for colocation settlement talks

The Federal Energy Regulatory Commission should reject a call for a 90-day pause in its deliberations over the PJM Interconnection’s rules for colocating data centers at power plants, according to PJM, major utilities and other organizations. “The national interest will be best served by a quick dismissal of this proceeding, and a ruling that the existing PJM Tariff remains just and reasonable,” PJM transmission owners said in a Wednesday filing urging FERC to dismiss a call for stakeholder settlement talks. “Rather than fighting about a wish list of new rules, the parties will then instead begin to focus on obtaining service under the rules in place today.” The transmission owners include utility companies such as American Electric Power, Dominion Energy, Duke Energy, Exelon, FirstEnergy and PPL Electric. “The record is clear — no matter how connected to the PJM transmission system, large loads pose both a safety and a reliability concern,” the utilities said. “It is unrealistic to ask the [transmission owners] to accede to these demands in the context of settlement procedures while those questions remain unresolved.” PJM also wants FERC to ignore the call for settlement discussions that was made in late April by the Electric Power Supply Association, the PJM Power Providers Group, Calpine, Cogentrix Energy Power Management, Constellation Energy Generation and LS Power Development. “The Commission should not pause its work on offering the industry guidance on a path forward for co-location arrangements,” PJM said in a Monday filing. The call for settlement talks lacks broad stakeholder support, PJM said, noting it is holding a workshop on “large load” issues on Friday. American Municipal Power, a wholesale power provider for public power utilities, and Northern Virginia Electric Cooperative and Northeastern Rural Electric Membership Corp. also oppose holding settlement talks. Beside the power generators and trade organizations,

Read More »

IRA’s fate unclear as Republicans look to finance megabill

Dive Brief: The Inflation Reduction Act – which passed in 2022 without any Republican support and is anticipated to cost taxpayers between $780 billion and $2 trillion over its first ten years – is likely to be targeted for cuts as the Republican-controlled Congress aims to cut spending by $2 trillion in order to cut taxes by $4.5 trillion. However, certain provisions of the IRA have won support with Republican lawmakers, setting up likely disagreements over cuts in the budget reconciliation process. That process is already expected to be “very contentious,” said Harry Godfrey, who leads Advanced Energy United’s federal investment and manufacturing working group. “[House Ways and Means Committee Chairman Jason Smith] and the Ways and Means Republicans will need revenue and will be seeking it, and have been saying all along that the IRA is an area they’re going to look at,” said Ryan Abraham, a principal with Ernst & Young’s Washington Council advisory practice. “But obviously there are some concerns among some members.” Dive Insight: Abraham noted the May 1 letter sent by 26 House Republicans to Chairman Smith, advocating for the preservation of the IRA’s 45U, 45Y, and 48E tax credits. The letter advocates on behalf of nuclear power specifically, “[urging Smith] to maintain federal investment in the existing nuclear energy fleet while accelerating deployment of the next generation of nuclear power technologies.” The 45U credit is the IRA’s zero-emission nuclear power production credit, while 48E and 45Y are technology-neutral credits, which were targeted in legislation introduced in April by Rep. Julie Fedorchak, R-N.D. “There’s a lot of concern that some of the bonus items that have been created in the IRA, like direct pay and transferability, which were also in that Fedorchak bill, could also get targeted,” Abraham said. However, he said, “Chairman Smith is aware

Read More »

Energy Department Aligns Award Criteria for For-profit, Non-profit Organizations, and State and Local Governments, Saving $935 Million Annually

WASHINGTON — The U.S. Department of Energy (DOE) today announced three new policy actions that are projected to save more than $935 million annually for the American taxpayer, while expanding American innovation and scientific research. In three new policy memorandums, the DOE announced that it will follow best practices used by fellow grant providers and limit “indirect costs” of DOE funding to 10% for state and local governments, 15% for non-profit organizations, and 15% for for-profit companies. The Energy Department expects to generate over $935 million in annual cost savings for the American people, delivering on President Trump’s commitment to bring greater transparency and efficiency to federal government spending. Estimated savings are based on applying the new policies to 2024 fiscal year spending. “This action ensures that Department of Energy funds are supporting state, local, for-profit and non-profit initiatives that make energy more affordable and secure for Americans, not funding administrative costs,” U.S. Secretary of Energy Chris Wright said. “By aligning our policy on indirect costs with industry standards, we are increasing accountability of taxpayer dollars and ensuring the American people are getting the greatest value possible from these DOE programs.” These policy actions follow an announcement made in April to limit financial support of “indirect costs” of DOE research funding at colleges and universities to 15%, saving an estimated additional $405 million annually. By enacting indirect cost limits, the Department aligns its practices with those common for other grant providers. The full three memorandums are available below: POLICY FLASH SUBJECT: Adjusting Department of Energy Financial Assistance Policy for State and Local Governments’ Financial Assistance Awards BACKGROUND: Pursuant to 5 U.S.C. 553(a)(2), the Department of Energy (“Department”) is updating its policy with respect to Department financial assistance funding awarded to state and local governments. Through its financial assistance programs (which include grants and cooperative agreements),

Read More »

Tech CEOs warn Senate: Outdated US power grid threatens AI ambitions

The implications are clear: without dramatic improvements to the US energy infrastructure, the nation’s AI ambitions could be significantly constrained by simple physical limitations – the inability to power the massive computing clusters necessary for advanced AI development and deployment. Streamlining permitting processes The tech executives have offered specific recommendations to address these challenges, with several focusing on the need to dramatically accelerate permitting processes for both energy generation and the transmission infrastructure needed to deliver that power to AI facilities, the report added. Intrator specifically called for efforts “to streamline the permitting process to enable the addition of new sources of generation and the transmission infrastructure to deliver it,” noting that current regulatory frameworks were not designed with the urgent timelines of the AI race in mind. This acceleration would help technology companies build and power the massive data centers needed for AI training and inference, which require enormous amounts of electricity delivered reliably and consistently. Beyond the cloud: bringing AI to everyday devices While much of the testimony focused on large-scale infrastructure needs, AMD CEO Lisa Su emphasized that true AI leadership requires “rapidly building data centers at scale and powering them with reliable, affordable, and clean energy sources.” Su also highlighted the importance of democratizing access to AI technologies: “Moving faster also means moving AI beyond the cloud. To ensure every American benefits, AI must be built into the devices we use every day and made as accessible and dependable as electricity.”

Read More »

Networking errors pose threat to data center reliability

Still, IT and networking issues increased in 2024, according to Uptime Institute. The analysis attributed the rise in outages due to increased IT and network complexity, specifically, change management and misconfigurations. “Particularly with distributed services, cloud services, we find that cascading failures often occur when networking equipment is replicated across an entire network,” Lawrence explained. “Sometimes the failure of one forces traffic to move in one direction, overloading capacity at another data center.” The most common causes of major network-related outages were cited as: Configuration/change management failure: 50% Third-party network provider failure: 34% Hardware failure: 31% Firmware/software error: 26% Line breakages: 17% Malicious cyberattack: 17% Network overload/congestion failure: 13% Corrupted firewall/routing tables issues: 8% Weather-related incident: 7% Configuration/change management issues also attributed for 62% of the most common causes of major IT system-/software-related outages. Change-related disruptions consistently are responsible for software-related outages. Human error continues to be one of the “most persistent challenges in data center operations,” according to Uptime’s analysis. The report found that the biggest cause of these failures is data center staff failing to follow established procedures, which has increased by about 10 percentage points compared to 2023. “These are things that were 100% under our control. I mean, we can’t control when the UPS module fails because it was either poorly manufactured, it had a flaw, or something else. This is 100% under our control,” Brown said. The most common causes of major human error-related outages were reported as:

Read More »

Liquid cooling technologies: reducing data center environmental impact

“Highly optimized cold-plate or one-phase immersion cooling technologies can perform on par with two-phase immersion, making all three liquid-cooling technologies desirable options,” the researchers wrote. Factors to consider There are numerous factors to consider when adopting liquid cooling technologies, according to Microsoft’s researchers. First, they advise performing a full environmental, health, and safety analysis, and end-to-end life cycle impact analysis. “Analyzing the full data center ecosystem to include systems interactions across software, chip, server, rack, tank, and cooling fluids allows decision makers to understand where savings in environmental impacts can be made,” they wrote. It is also important to engage with fluid vendors and regulators early, to understand chemical composition, disposal methods, and compliance risks. And associated socioeconomic, community, and business impacts are equally critical to assess. More specific environmental considerations include ozone depletion and global warming potential; the researchers emphasized that operators should only use fluids with low to zero ozone depletion potential (ODP) values, and not hydrofluorocarbons or carbon dioxide. It is also critical to analyze a fluid’s viscosity (thickness or stickiness), flammability, and overall volatility. And operators should only use fluids with minimal bioaccumulation (the buildup of chemicals in lifeforms, typically in fish) and terrestrial and aquatic toxicity. Finally, once up and running, data center operators should monitor server lifespan and failure rates, tracking performance uptime and adjusting IT refresh rates accordingly.

Read More »

Cisco unveils prototype quantum networking chip

Clock synchronization allows for coordinated time-dependent communications between end points that might be cloud databases or in large global databases that could be sitting across the country or across the world, he said. “We saw recently when we were visiting Lawrence Berkeley Labs where they have all of these data sources such as radio telescopes, optical telescopes, satellites, the James Webb platform. All of these end points are taking snapshots of a piece of space, and they need to synchronize those snapshots to the picosecond level, because you want to detect things like meteorites, something that is moving faster than the rotational speed of planet Earth. So the only way you can detect that quickly is if you synchronize these snapshots at the picosecond level,” Pandey said. For security use cases, the chip can ensure that if an eavesdropper tries to intercept the quantum signals carrying the key, they will likely disturb the state of the qubits, and this disturbance can be detected by the legitimate communicating parties and the link will be dropped, protecting the sender’s data. This feature is typically implemented in a Quantum Key Distribution system. Location information can serve as a critical credential for systems to authenticate control access, Pandey said. The prototype quantum entanglement chip is just part of the research Cisco is doing to accelerate practical quantum computing and the development of future quantum data centers.  The quantum data center that Cisco envisions would have the capability to execute numerous quantum circuits, feature dynamic network interconnection, and utilize various entanglement generation protocols. The idea is to build a network connecting a large number of smaller processors in a controlled environment, the data center warehouse, and provide them as a service to a larger user base, according to Cisco.  The challenges for quantum data center network fabric

Read More »

Zyxel launches 100GbE switch for enterprise networks

Port specifications include: 48 SFP28 ports supporting dual-rate 10GbE/25GbE connectivity 8 QSFP28 ports supporting 100GbE connections Console port for direct management access Layer 3 routing capabilities include static routing with support for access control lists (ACLs) and VLAN segmentation. The switch implements IEEE 802.1Q VLAN tagging, port isolation, and port mirroring for traffic analysis. For link aggregation, the switch supports IEEE 802.3ad for increased throughput and redundancy between switches or servers. Target applications and use cases The CX4800-56F targets multiple deployment scenarios where high-capacity backbone connectivity and flexible port configurations are required. “This will be for service providers initially or large deployments where they need a high capacity backbone to deliver a primarily 10G access layer to the end point,” explains Nguyen. “Now with Wi-Fi 7, more 10G/25G capable POE switches are being powered up and need interconnectivity without the bottleneck. We see this for data centers, campus, MDU (Multi-Dwelling Unit) buildings or community deployments.” Management is handled through Zyxel’s NebulaFlex Pro technology, which supports both standalone configuration and cloud management via the Nebula Control Center (NCC). The switch includes a one-year professional pack license providing IGMP technology and network analytics features. The SFP28 ports maintain backward compatibility between 10G and 25G standards, enabling phased migration paths for organizations transitioning between these speeds.

Read More »

Engineers rush to master new skills for AI-driven data centers

According to the Uptime Institute survey, 57% of data centers are increasing salary spending. Data center job roles that saw the highest increases were in operations management – 49% of data center operators said they saw highest increases in this category – followed by junior and mid-level operations staff at 45%, and senior management and strategy at 35%. Other job categories that saw salary growth were electrical, at 32% and mechanical, at 23%. Organizations are also paying premiums on top of salaries for particular skills and certifications. Foote Partners tracks pay premiums for more than 1,300 certified and non-certified skills for IT jobs in general. The company doesn’t segment the data based on whether the jobs themselves are data center jobs, but it does track 60 skills and certifications related to data center management, including skills such as storage area networking, LAN, and AIOps, and 24 data center-related certificates from Cisco, Juniper, VMware and other organizations. “Five of the eight data center-related skills recording market value gains in cash pay premiums in the last twelve months are all AI-related skills,” says David Foote, chief analyst at Foote Partners. “In fact, they are all among the highest-paying skills for all 723 non-certified skills we report.” These skills bring in 16% to 22% of base salary, he says. AIOps, for example, saw an 11% increase in market value over the past year, now bringing in a premium of 20% over base salary, according to Foote data. MLOps now brings in a 22% premium. “Again, these AI skills have many uses of which the data center is only one,” Foote adds. The percentage increase in the specific subset of these skills in data centers jobs may vary. The Uptime Institute survey suggests that the higher pay is motivating workers to stay in the

Read More »

Microsoft will invest $80B in AI data centers in fiscal 2025

And Microsoft isn’t the only one that is ramping up its investments into AI-enabled data centers. Rival cloud service providers are all investing in either upgrading or opening new data centers to capture a larger chunk of business from developers and users of large language models (LLMs).  In a report published in October 2024, Bloomberg Intelligence estimated that demand for generative AI would push Microsoft, AWS, Google, Oracle, Meta, and Apple would between them devote $200 billion to capex in 2025, up from $110 billion in 2023. Microsoft is one of the biggest spenders, followed closely by Google and AWS, Bloomberg Intelligence said. Its estimate of Microsoft’s capital spending on AI, at $62.4 billion for calendar 2025, is lower than Smith’s claim that the company will invest $80 billion in the fiscal year to June 30, 2025. Both figures, though, are way higher than Microsoft’s 2020 capital expenditure of “just” $17.6 billion. The majority of the increased spending is tied to cloud services and the expansion of AI infrastructure needed to provide compute capacity for OpenAI workloads. Separately, last October Amazon CEO Andy Jassy said his company planned total capex spend of $75 billion in 2024 and even more in 2025, with much of it going to AWS, its cloud computing division.

Read More »

John Deere unveils more autonomous farm machines to address skill labor shortage

Join our daily and weekly newsletters for the latest updates and exclusive content on industry-leading AI coverage. Learn More Self-driving tractors might be the path to self-driving cars. John Deere has revealed a new line of autonomous machines and tech across agriculture, construction and commercial landscaping. The Moline, Illinois-based John Deere has been in business for 187 years, yet it’s been a regular as a non-tech company showing off technology at the big tech trade show in Las Vegas and is back at CES 2025 with more autonomous tractors and other vehicles. This is not something we usually cover, but John Deere has a lot of data that is interesting in the big picture of tech. The message from the company is that there aren’t enough skilled farm laborers to do the work that its customers need. It’s been a challenge for most of the last two decades, said Jahmy Hindman, CTO at John Deere, in a briefing. Much of the tech will come this fall and after that. He noted that the average farmer in the U.S. is over 58 and works 12 to 18 hours a day to grow food for us. And he said the American Farm Bureau Federation estimates there are roughly 2.4 million farm jobs that need to be filled annually; and the agricultural work force continues to shrink. (This is my hint to the anti-immigration crowd). John Deere’s autonomous 9RX Tractor. Farmers can oversee it using an app. While each of these industries experiences their own set of challenges, a commonality across all is skilled labor availability. In construction, about 80% percent of contractors struggle to find skilled labor. And in commercial landscaping, 86% of landscaping business owners can’t find labor to fill open positions, he said. “They have to figure out how to do

Read More »

2025 playbook for enterprise AI success, from agents to evals

Join our daily and weekly newsletters for the latest updates and exclusive content on industry-leading AI coverage. Learn More 2025 is poised to be a pivotal year for enterprise AI. The past year has seen rapid innovation, and this year will see the same. This has made it more critical than ever to revisit your AI strategy to stay competitive and create value for your customers. From scaling AI agents to optimizing costs, here are the five critical areas enterprises should prioritize for their AI strategy this year. 1. Agents: the next generation of automation AI agents are no longer theoretical. In 2025, they’re indispensable tools for enterprises looking to streamline operations and enhance customer interactions. Unlike traditional software, agents powered by large language models (LLMs) can make nuanced decisions, navigate complex multi-step tasks, and integrate seamlessly with tools and APIs. At the start of 2024, agents were not ready for prime time, making frustrating mistakes like hallucinating URLs. They started getting better as frontier large language models themselves improved. “Let me put it this way,” said Sam Witteveen, cofounder of Red Dragon, a company that develops agents for companies, and that recently reviewed the 48 agents it built last year. “Interestingly, the ones that we built at the start of the year, a lot of those worked way better at the end of the year just because the models got better.” Witteveen shared this in the video podcast we filmed to discuss these five big trends in detail. Models are getting better and hallucinating less, and they’re also being trained to do agentic tasks. Another feature that the model providers are researching is a way to use the LLM as a judge, and as models get cheaper (something we’ll cover below), companies can use three or more models to

Read More »

OpenAI’s red teaming innovations define new essentials for security leaders in the AI era

Join our daily and weekly newsletters for the latest updates and exclusive content on industry-leading AI coverage. Learn More OpenAI has taken a more aggressive approach to red teaming than its AI competitors, demonstrating its security teams’ advanced capabilities in two areas: multi-step reinforcement and external red teaming. OpenAI recently released two papers that set a new competitive standard for improving the quality, reliability and safety of AI models in these two techniques and more. The first paper, “OpenAI’s Approach to External Red Teaming for AI Models and Systems,” reports that specialized teams outside the company have proven effective in uncovering vulnerabilities that might otherwise have made it into a released model because in-house testing techniques may have missed them. In the second paper, “Diverse and Effective Red Teaming with Auto-Generated Rewards and Multi-Step Reinforcement Learning,” OpenAI introduces an automated framework that relies on iterative reinforcement learning to generate a broad spectrum of novel, wide-ranging attacks. Going all-in on red teaming pays practical, competitive dividends It’s encouraging to see competitive intensity in red teaming growing among AI companies. When Anthropic released its AI red team guidelines in June of last year, it joined AI providers including Google, Microsoft, Nvidia, OpenAI, and even the U.S.’s National Institute of Standards and Technology (NIST), which all had released red teaming frameworks. Investing heavily in red teaming yields tangible benefits for security leaders in any organization. OpenAI’s paper on external red teaming provides a detailed analysis of how the company strives to create specialized external teams that include cybersecurity and subject matter experts. The goal is to see if knowledgeable external teams can defeat models’ security perimeters and find gaps in their security, biases and controls that prompt-based testing couldn’t find. What makes OpenAI’s recent papers noteworthy is how well they define using human-in-the-middle

Read More »
More Articles