search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Feature: Hardware design


Breaking crypto with hardware attacks


T


By Trevor Martin, ARM Technical Specialist, Hitex However, there is another way: a range


he algorithms used in modern digital cryptography are very resistant to any form of cryptoanalysis; for algorithms such as the Advanced Encryption


Standard (AES) there is no known break other than a brute force attack of trying every possible key. With a 128-bit or 256-bit key size this is computationally infeasible.


Figure 1: Basic hardware setup for power analysis


of hardware attacks provide reliable, repeatable methods to break a system and compromise secrets such as cryptography keys. Historically, small embedded systems with bespoke code have not been a target for hackers – they are a lot of effort for little reward. But, in the ever-growing IoT world where large fleets of devices are used, many with common soſtware components, this


era is nearing its end. Combine this with many small companies with limited budgets using low-cost microcontrollers (MCUs) in ever more security sensitive roles, and we are creating a new generation of tempting targets. Here I want to look at a range of hardware


attacks that are feasible, low cost and reproducible for many microcontroller- based systems. Typically, these rely on some form of side channel attack that today’s cryptographic algorithms are not designed to resist. As a developer you need to understand these growing threats and, where necessary, introduce testing to validate your hardware/soſtware and any mitigations that have been added. As we are developing the system we have


the advantage that we can do white box testing that allows us to introduce trigger hooks to synchronise external equipment (oscilloscope, glitch generator, EMF probe, etc.) to align with critical code execution. Rather than trying to hack a system,


the question to answer is: “Is it possible to fault the system and have my mitigations worked?”


20 February 2026 www.electronicsworld.co.uk


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48