Digital security is always a moving target, with no one device or system every being truly secure. Whether its cryptographic systems being compromised, software being hacked, or baked-in hardware vulnerabilities, it seems there is always a hole to be found. [Max Justicz] has a taste for such topics, and decided to explore the possibility of creating a secure communications device using a pair of LCDs.
In a traditional communications system, when a message is decrypted and the plaintext is displayed on screen, there’s a possibility that any other software running could capture the screen or memory state, and thus capture the secret data. To get around this, [Max]’s device uses a concept called visual cryptography. Two separate, independent systems with their own LCD each display a particular pattern. It is only when the two displays are combined together with the right filters that the message can be viewed by the user, thanks to the visual XOR effect generated by the polarized nature of LCDs.
The device as shown, working with both transparent OLEDs and traditional LCDs, is merely a proof of concept. [Max] envisions a device wherein each display is independently sourced, such that even if one is compromised, it doesn’t have the full message, and thus can’t compromise the system. [Max] also muses about the problem of side-channel attacks, and other factors to consider when trying to build a truly secure system.
We love a good discussion of cryptography and security around here; [John McMaster]’s talk on crypto ignition keys was a particular hit at Supercon last year. Video after the break.
Continue reading “Cryptographic LCDs Use The Magic Of XOR”
With more and more embedded systems being connected, sending state information from one machine to another has become more common. However, sending large packets of data around on the network can be bad both for bandwidth consumption and for power usage. Sure, if you are talking between two PCs connected with a gigabit LAN and powered from the wall, just shoot that 100 Kbyte packet across the network 10 times a second. But if you want to be more efficient, you may find this trick useful.
As a thought experiment, I’m going to posit a system that has a database of state information that has 1,000 items in it. It looks like an array of RECORDs:
It doesn’t really matter what the topics and the data are. It doesn’t really matter if your state information looks like this at all, really. This is just an example. Given that it is state information, we are going to make an important assumption, though. Most of the data doesn’t change frequently. What most and frequently mean could be debated, of course. But the idea is that if I’m sending data every half second or whatever, that a large amount isn’t going to change between one send and the next.
Continue reading “A Real Time Data Compression Technique”
A few semesters back, [Jordan] was in an Intro to Hardware Security course at CMU. The final project was open ended, and where some students chose projects like implementing a crypto algorithm or designing something on an FPGA, [Jordan] decided to do something a little more ambitious. He wanted to decapsulate and reverse engineer an IC. No, this isn’t taking a peek at billions of transistors — [Jordan] chose a 74-series Quad XOR for this project — but it does show what goes into reverse engineering silicon, and how even simple chips can be maddeningly confusing.
The first step to reverse engineering a chip is decapsulation, and for this [Jordan] had two options. He could drop acid, or he could attack a ceramic package with an endmill. While hot nitric acid is effective and fun, it is a bit scary, so [Jordan] mounted a few chips in a 3D printed holder wedged in the vice on his mill. By slowly bringing the Z axis down a few thou at a time, he was able to find the tiny 1 mm square bit of silicon embedded in this chip. With the help of a grad student and the cleanroom, this square of sand was imaged with a very nice microscope.
Now that [Jordan] had an image of the silicon itself, he had to reverse engineer the chip. You might think that with less than a dozen transistors in there, designing an XOR out of transistors is something anyone with a bit of Minecraft experience can do. This line of thinking proved to be a trap. Technically, this wasn’t an XOR gate. It was a transmission gate XNOR gate with a big inverter on the output. Logically, it’s the same, but when it comes to silicon fabrication, the transmission gate XNORs aren’t able to sink or source a lot of current. By designing the chip as an XNOR with an inverter, the chip designers were able to design a simple chip that could still meet the spec.
While [Jordan] managed to reverse engineer the chip, this was quite possibly the simplest chip he could reverse engineer. The Quad XOR is just the same silicon repeated four times, anyway. This is the baseline for all efforts to reverse engineer silicon, and there were still a few confusing traps.
Computers built using discrete logic chips? Seen it. Computers from individual transistors? Impressive, but it’s been done. A computer built out of electromechanical relays? Bring on the ozone!
The aptly named [Clickity Clack]’s new YouTube channel promises to be very interesting if he can actually pull off a working computer using nothing but relays. But even if he doesn’t get beyond the three videos in the playlist already, the channel is definitely worth checking out. We’ve never seen a simpler, clearer explanation of binary logic, and [Clickity Clack]’s relay version of the basic logic gates is a great introduction to the concepts.
Using custom PCBs hosting banks of DPDT relays, he progresses from the basic AND and XOR gates to half adders and full adders, explaining how carry in and carry out works. Everything is modular, so four of his 4-bit adder cards eventually get together to form a 16-bit adder, which we assume will be used to build out a very noisy yet entertaining ALU. We’re looking forward to that and relay implementations of the flip-flops and other elements he’ll need for a full computer.
And pay no mind to our earlier dismissal of non-traditional computer projects. It’s worth checking out this discrete 7400 logic computer and this all-transistor build. They’re impressive too in their own way, if a bit quieter than [Clickety Clack]’s project.
Continue reading “Relay Computer Starts With An Adder That Makes A Racket”
A few days ago, we saw a project that used a Teensy to build a Universal 2nd Factor (U2F) key. While this project was just an experiment in how to implement U2F on any ‘ol microcontroller, and the creator admitted it wasn’t very secure, the comments for that post said otherwise: “making your own thing is the ONLY way to be secure,” read the comments.
In a stunning turn of events, writing comments on a blog post doesn’t mean you know what you’re talking about. It turns out, to perform a security analysis of a system, you need to look at the code. Shocking, yes, but [makomk] took a good, hard look at the code and found it was horribly broken.
The critical error of the Teensy U2F key crypto is simply how U2F is performed. During authentication, the device sends the U2F key handle to whatever service is trying to authenticating it. Because the key in the Teensy implementation is only ‘encrypted’ with XOR, it only takes 256 signing requests to recover the private key.
The original experimentation with using the Teensy as a U2F key was an educational endeavor, and it was never meant to be used by anyone. The attack on this small lesson in security is interesting, though, and [makomk] wrote a proof of concept that demonstrates his attack. This could be used to perform attacks from a remote server, but hopefully that won’t happen, because the original code should never be used in the wild.
[Phillip] wanted to play with the C preprocessor. He decided to do that by creating a 4 bit full adder. We know this is pretty useless in everyday life, but it was a great learning experience. The beauty of this adder is right at the start. [Phillip] defines truth tables for XOR and AND. He’s able to then create strings that reference these truth tables.
For example: the first line of [Phillip’s] AND table is #define AND_00 0. If the preprocessor concatenates strings that equal “AND_00” they will then be converted to 0. This is the groundwork for the half adder .
The next step is the operational logic, which of course falls upon macros:
/* Full adder macros */
/* Out = (A ^ B) ^ cin */
#define FULL_ADD_OUT( a, b, cin ) \
XOR( XOR( a, b ), cin )
/* Carry_out = (A & B) ^ (Carry_in & (A ^ B)) */
/* The standard adder uses OR for the last 'gate' - this
can safely be changed to XOR, which has been done here
to avoid defining an OR operator */
#define FULL_ADD_CARRY( a, b, cin ) \
XOR( AND( XOR( a, b ), cin ), AND( a, b ) )
Continue reading “Create A Full Adder Using The C Preprocessor”
Did you know that most AVR chips have a type of hardware exclusive OR (XOR) option when it comes to the logic levels of the output pins? If you look in the datasheet (the image above is a screenshot from an ATtiny13 datasheet) you’ll find a section on Toggling the Pin. It turns out that if you set a PORT as an output, writing logic one to the corresponding PIN register will toggle the logic levels of that out. This is really easy to overlook if you’re writing in C, but I’ve been working on learning a bit of assembler language and found this to be very useful. Keep reading after the break and I’ll tell you how I happened upon this info and what it’s good for.
Continue reading “Hardware XOR For Output Pins On AVR Microcontrollers”