انتخاب واحد پولی:
فارسی انگلیسی
سبد خرید: (0) مورد
خوش آمدید, کاربر گرامی
پشتیبانی آنلاین
Live Support
شاخه ها
اطلاعيه ها
اطلاعيه هامرا از تغييرات محصول Chipwhisperer-Lite SCA side-channel analysis of the development board آگاه كن.
سبد خريد
 
0 مورد
مقایسه محصولات
محصولی برای مقایسه انتخاب نشده است!
ورود به سيستم
آدرس پست الكترونيك:
كلمه عبور:

کلمه عبورتان را فراموش کرده اید؟
هنوز ثبت نام نکرده اید؟
تگ محصولات
تسلست
مقالات
مقالات جدید
تمامی مقالات
تمامی موضوعات
 مقالات متفرقه
RSS مقالات

Chipwhisperer-Lite SCA side-channel analysis of the development board[WRL-00162]کد کالا : WRL-00162

Chipwhisperer-Lite SCA side-channel analysis of the development board
قیمت: ناموجود
 
 
نظرات موجود:1

DESCRIPTION


ChipWhisperer is the first open-source toolchain for embedded hardware security research including side-channel power analysis and glitching. The innovative synchronous capture technology is unmatched by other tools, even from commercial vendors. Similar commercial equipment is too expensive ($30k+), and being closed-source limits usefulness for academics. Instead this project bridges the gap between academic research and in-the-trenches engineering. Several peer-reviewed publications describe the design, matched with hours of hands-on tutorials for getting started. 

The objective of ChipWhisperer is nothing short of revolutionizing the entire embedded security industry. Every designer who uses encryption in their design should be able to perform a side-channel attack, and understand the ramifications of these attacks on their designs. The open-source nature of the ChipWhisperer makes this possible, and my hope is that it becomes the start of a new era of hardware security research.

DETAILS



Links to project details (GIT, Wiki, Docs) are on the left. The laziest intro to this project is the 2-minuite video created for THP Quarterfinals (i.e. the first video I made):

What's This About?

Lots of people have tried to design secure systems, and alas there is lots of failures. But what if you did everything correct: no buffer overflows, no unsanitized inputs, no default passwords. Unfortunately this isn't good enough - even perfectly implemented encryption algorithms such as AES-256 will reveal encryption keys. It's not due to incorrect implementation, it's a fundamental artifact of the design.

This has been known for a long time - the first paper on this was published in 1998. But if you are an engineer or independent researcher tools to get started are expensive, or require you to do a lot of work yourself scripting together lower-cost tools. This project is my attempt to eliminate this problem.

I'm eliminating the problem for good by making my tools open source. Because this whole area is an active research area, the tools need to be open source. This isn't a case of attempting to seem sexy by adding the word 'open-source', but placing something of commercial value into the open-source domain, in the hope it spurs a larger community. Think of something like Wireshark - it's extremely valuable, and could easily be sold as a high-end product. But most of that value comes from it being open source, and hence containing a huge array of protocol dissectors, far beyond what a commercial vendor could support. For my designs, part of the larger community includes hours of tutorials on this area - the objective of ChipWhisperer is not just the engineering that went into the software and hardware, but having tutorials and documentation that could be used as a complete course in side-channel analysis and glitching.

It's also worth stressing that there is no 'tricks' to the open-source nature of this project. It's not just part of the design that's open source, I'm not using a restrictive non-commercial license, and I've already had other people build these units from PCB design files. The objective of this is project is to open up this area of research to a much wider audience, and the commercial value I lose from limiting how much I can charge for the tools (since anyone can make them) is far offset by the greater value added to the community.

It's useful to point out how critical this field of embedded security has become, and why it's interesting to see attacks against AES (which I tend to focus on in my demos). The 'Internet of Things' requires some wireless communication network - be it IEEE 802.15.4ZigBee (which uses 802.15.4), or Bluetooth Low Energy. Since these are wireless protocols, security is of paramount importance - and the designers acknowledge that. Attacks against AES are interesting because all three of the previous protocols use AES-128 for security. Unfortunately AES-128 isn't just a "check box" that indicates your system is secure, despite one document listing that because Bluetooth low energy has 128 bit AES, it's "secure against attack and hacking" (see page 45). The idea that implementations are secure because the underlying algorithm is secure will cost somebody a lot of money when it blows up in their face, and they have to fix millions of already deployed devices.

Assuming designers aren't foolish enough to send encryption keys over SPI (see Travis Goodspeed's attacks), and have actually done the implementation correctly, and haven't introduced backdoors, we can still break the AES implementation. This isn't a theoretical attack, but a real-world attack that every embedded designer needs to understand. It's clear that very few designers are aware of this issue, based on how infrequently it is brought up when looking over datasheets, design specifications, and application notes. And no, it's not enough to use hardware accelerators - an attack has been demonstrated against the XMEGA crypto engine (presentation slidesdetails on page 77 of thesisarticle at ACM behind paywall). See the 2684 pages of Bluetooth specification for example, not a hit for 'side channel' to be found:

ChipWhisperer won't secure the internet of things. But it will hopefully jolt people into believing that "secure because math" isn't a good enough answer. Even these theoretically unbreakable cryptographic algorithms have great weaknesses during implementation, and they may be much easier to break than you ever assumed. So let's start looking into how this works.

Side channel analysis takes advantage of the fact that changing the state of a digital line uses a small amount of power. Switching from a 'zero' to a 'one' takes a small charge for example. Many digital ICs will also push the lines into a 'pre-charge' state in-between transitions to reduce the worst-case time delay, such that on every cycle the bus goes from an intermediate state to a final state. For us this means we can almost directly infer the Hamming Weight (number of one's) on a digital bus based on the power consumption.

So what does that give us? Consider that we had the following system, which is a simple XOR of some input data with a secret key, where we don't see the final output:

While we can build the following matrix, given some known inputs, along with the associated hamming weights based on the power measurement:

Then one can simply guess what the secret key was! Based on our guess we can determine which guess best aligns with the real measurements. In the following example if the secret key was 0xEF, we would end up with the hamming weight matching our observations:

Finally, the reason this works so well is that it allows us to break a single byte of the encryption key at a time! Thus the minimal guess-and check means guessing 256 possibilities for each byte, and doing that 16 times:

For more details see my write-up on the theory of a CPA attack, along with a nice example of step-by-step breaking of the AES using Python from my ChipWhisperer tutorial list. For the attack to work, we basically just need to be able to tell the encryption/decryption algorithm to operate while we monitor the power, and know either the output or input to the system.

This can be done with ~20 power traces on an AVR device for example, so it's not a case of taking an unrealistic number of measurements. For example see a real-time example of me breaking an AES-128 implementation in 120 seconds.

Glitching is another devious attack on embedded systems. This takes advantage of the fact that at some point in your code you'll have a test of the input password, signature, or whatever else. So consider we have this code:

It's actually possible to manipulate the system to cause that check to fail, or for instructions to be skipped. One method of doing this is inserting a quick glitch into the clock, as the following example from the ChipWhisperer shows:

This "double-edge" causes timing errors in the target device. The result of this varies, but often results in an instruction skip or the wrong result of a comparison to be loaded. As an example see my video showing clock glitching breaking a password check.

If you are looking for some additional detail see the full ChipWhisperer clock glitching tutorial, which includes a 35 minute video tutorial.

Even somewhat more interesting, is the fact you can do this with 'power glitching'. This means inserting some sort of low-voltage spike into the VCC line of the device you are targetting. This works even for advanced chips, like a Raspberry Pi or Android Smartphone. The VCC line glitch might look like this:

This can cause a user-land application to fail on something like an Android smartphone - here is an example where I'm causing an incorrect calculation, this example comes from my project log update:

There is a full ChipWhisperer VCC glitching tutorial which targets an AVR microcontroller, in the same fashion as the clock glitching tutorial. Now that you get an idea of why these attacks are so interesting, let's look at what ChipWhisperer can do.

The system is a fusion of closely operating FPGA blocks and a Python interface communicating over a high-speed USB 2.0 interface. It even uses partial reconfiguration to reprogram the Spartan 6 FPGA during operation to fine-tune certain parameters that would otherwise be fixed when implementing the FPGA. Remote database storage of traces is used to power high-performance analysis, levelling the playing field for the independent researcher who doesn't have access to costly computing hardware.

Having the computer connectivity of the hardware is fundamental to the operation of this device. In addition it's possible (and sometimes required) to have the device split over several locations via a network. This can mean the ChipWhisperer is running on one computer, with data being saved to a larger network store. Even for researchers who do have local access to a high-performance computer, the remote storage is often useful, since the physical attack may be occurring at a different spot from the analysis computer.

The blocks themselves can be implemented into many different FPGAs - this system is not limited to the capture hardware created as part of this project.

افزودن به لیست مقایسه نظرات بازگشت
کپی‌رایت © 2024 ایران ماژول الکترونیک
راه اندازی شده توسط فروشگاه ساز ویرچو