At WWDC in 2020, Apple announced Touch ID and Face ID authentication for the Web as a new feature in Safari.
We are not at the Precipice of a GPS Disaster
Are we at risk of a GPS crisis? Attacks on GPS are commonplace in various forms, but this doesn’t mean GPS is the problem, but rather how we use it is.
Application Trust is Hard, but Apple does it Well
On November 12, 2020 Apple released macOS Big Sur. In the hours after the release went live, somewhere in Apple's infrastructure an OCSP esponder cried out in pain…
A Treatise on Voting Machines
he Voting Machine Village, round two, took place at DEFCON this past weekend.
As I write this at the end of 2017, I think it's safe to say this year was the year of the breach. Major privacy breaches achieved public notoriety. Huge corporations realized that trusting supply chain is actually a real problem...
IoT and computer security fears are at the forefront of the news cycle. Foreign hackers, malfeasants from America or government-sponsored entities are hacking your home...
We're starting to see Bluetooth Low Energy (BLE) show up everywhere. Fitness trackers, IoT doohickeys, deadbolt locks and even security tokens are showing up with BLE. By treating your cell phone as the center of life, things have never been more convenient.
A recent project led to spelunking through a proprietary RTOS built for an embedded device. The engineers who worked on this project were quite bright. There was extensive use of dlmalloc, in the form of the verison embedded in Newlib.
Devices that provide 'local' APIs (i.e. services exposed to the local network) tend to be a lot easier to exploit. A buffer overflow here. A command injection there. Pre-authorization exploits abound! But, devices that only listen to external services for commands tend to be harder targets.
Sometimes you just want to verify that the user has a secret. A secret comes in many forms - a key, a random value, a secret function. How could we verify a user has a secret without building a heavy, cryptographically secure channel?
Most cryptosystems rely on access to true random data. For public key schemes like RSA, you need to generate two random primes to generate your keys. Let's look at how hard it can be to generate real random numbers.
Do you need a full-fledged, pre-emptive multitasking operating system? Will a simple RTOS do the job? Let's look at where the wrong tool has been used for the job.
Dynamic allocation will always undermine determinism and performance of a system. True real time systems will always operate on fixed bounds for every aspect of the system. What are some approaches to simplify memory management?
Firmware is made up of many layers. These are obvious: a bootloader, an RTOS, your application(s), etc. At startup you want to be able to guarantee the integrity of all that code.
We've discussed why you don't fix IVs for AES-CBC. We've touched on the limitations of only using symmetric keys in your application. We've even covered the challenges of protecting symmetric keys. But one sin we have not discussed is fixing your keys.
Public Key Cryptography simplifies authentication. We can use a public key to authenticate firmware updates signed with the private key. Everything seems pretty clear at this point. But we need to keep our keys secure! How can we approach that...
So we stole the keys to the castle, now what? Let's look at how we can take the key and IV we've extracted for our device to decrypt the payloads. Then we can start reverse engineering the communication protocol used by the device.
It seems that Pokemon Go has taken the world by storm. Let's zero in on the issue of application capabilities, or permissions in Android parlance. And let's talk about asking for too much of the user.