You can simply boot into DFU mode and upload arbitrary (signed) firmware via USB that way. This is how forensics-without-Apple's-help works with iPhones that had vulnerable boot ROMs (and thus you could bypass the signature requirement). It's not that Apple has built this technology in, instead, they haven't built technology to stop this use case. The iPhone design from the very beginning included the ability to boot off of USB into a ramdisk, as this is how iTunes restores work, and by extension, that can be used to extract data and/or generally replace any behavior of the standard OS if you have Apple's keys. Regular restores using the official mechanism may or may not in practice require the PIN to work, but the underlying DFU technology allows for that kind of bypass because it doesn't have any mechanism to ensure otherwise.
This is something that I've mentioned in the past, before this debacle: that large parts of the iOS security system are just policy decisions made by their software, and that they are therefore trivially vulnerable to replacing said software - which Apple can do, as they have the keys. This allows the system to be more flexible, as it's a lot easier to write code to implement a policy than to design a cryptographic system that guarantees it.
I hope that in future iPhone versions Apple uses cryptography to secure user data in the face of unexpected updates (i.e. the requirement for a PIN is actually enforced cryptographically, and if you attempt a cold restore without the PIN you inevitably lose access to user data storage keys), but right now, that is not the case.
Android, comparatively, tends to have a weaker security system, but, on the other hand, uses "hard" crypto-based security in places where Apple doesn't. For example, iPhones use full disk encryption but it is not based on the user PIN - so, again, that's a policy system, not cryptographically guaranteed - which means that some/most data is encrypted with your PIN in newer iOS versions (at another layer), but the metadata isn't (filenames, and perhaps data that is accidentally stored without adequate file-level encryption config), and anything that isn't based on the PIN can be extracted by Apple. Android full disk encryption is cryptographically based on your PIN/passphrase (which you enter on boot), and therefore guarantees that every last bit of data and metadata is safe without depending on OS policy.
shouldn't be forced to create a backdoor to add to a phone, but they should be required to unlock any existing phones. And to most of the audience that sounds reasonable, but when you actually take a second to think about it you see blatant political doublespeak.
But it actually is reasonable!
The reason why Apple can be forced to unlock the iPhone in question is because current iPhone security still depends wholly on trusting Apple's firmware. They are not being asked to create a backdoor - they are being asked to exercise a backdoor that they already have. They already have the keys to the kingdom.
Now, what would be unreasonable is for the FBI to require that Apple don't actually fix this in newer iPhone iterations, thereby making it technologically impossible to comply. Which I hope they do (fix it, that is - there are technical ways of plugging this hole). But, in the meantime, this is no different from previous iOS versions where Apple willingly performed data extraction for law enforcement. The technicalities have changed, but only somewhat - Apple can still, in practice, extract all of this iPhone's data, given their master firmware signing keys. So, the only thing that has actually changed is that Apple has changed their policy to start refusing these requests.
Now, whether you believe that technology companies should be able to be compelled to help law enforcement is another matter. But, many arguments being used by the pro-Apple side (such as the "this would create a backdoor" argument) are nonsense from a technical standpoint. In practice, literally the only change of substance is that Apple is now resisting this kind of request, where they didn't in the past - and none of this has anything to do with technical security measures in iOS at all, even though Apple is trying hard to make people believe that it does (and, in some cases, actively lying about technical details).
RFC1952 clearly states that the mtime header is a POSIX timestamp, i.e., it is in universal time and not local time. The author of TFA somehow either completely missed or neglected to mention the fact that, per spec, there is no leakage of the timezone, and in fact two of his examples demonstrate exactly that.
Of the three examples cited in TFA, two of them - reddit.com and instagram.com - follow the spec and use POSIX time. Just run the php tool from TFA and you'll see that the time returned matches the current UTC time. Those servers aren't leaking their location because they follow the spec.
Only one example - bing.com - uses something other than POSIX time. Surprise surprise, some Windows-based server - presumably IIS? - ignores the standard and leaks the timezone in the process.
Now the question is, are people seriously running TOR hidden services on Windows machines? That just seems like asking for trouble. The operational security requirements of TOR hidden services are significantly higher than your average server, and I bet the chances of screwing that up with a Windows server are much higher. Leaking the timezone is probably the least of your worries in that case.
TL;DR Some Windows web server mis-implements the gzip standard and leaks the local timezone in the process. Spec-compliant web servers are not affected. TFA mis-identified two compliant servers as being affected. TFA did not list any Tor hidden services that are affected to allow for confirmation. This is mostly a non-issue.
The refusal is, to an extent, a PR stunt though. They have aided investigations (via modified firmware that can dump data) in the past. This case isn't significantly different from that, and what the FBI is asking for is, from a technical standpoint, reasonable (Apple already signs all iPhone firmwares to individual phones, so it doesn't even have a risk of compromising other users and doesn't even need a specific mechanism for that - the stuff about compromising security for everyone is FUD, because regardless of whether the FBI gets what it wants or not, the security is still fully at the mercy of Apple's bidding either way, not the FBI).
The way I see it, this is what happened: Apple used to help investigators. Then they increased the security of their platform. Then the FBI realized that they could still break in with help just as before, because in current iPhone generations anti-bruteforcing restrictions can be bypassed by modified firmware. Then Apple panicked because they don't want to go back to assisting investigations, and they've been saying that their platform is secure (without admitting that it isn't if they sign insecure firmware post-facto - it isn't secure against an attacker that colludes with -or compromises- Apple). So now they're putting up a fight, while simultaneously trying to spin it as the FBI wanting to compromise security for everyone else (it doesn't, they already have a mechanism to lock it to a given phone, this is how they stop jailbreakers from downgrading).
I don't agree with the FBI having the power to do compel Apple to do this, but so far, the only things that have changed are that Apple stopped agreeing to help, and that they claim their platform is more secure now - but it isn't, not against this particular attack. The FBI isn't asking for something radically different from what Apple used to provide, nor is it more dangerous than what Apple used to provide, it's just that Apple has done a 180 and started saying now, while wishy-washingly throwing in security implications that aren't real, trying to imply that they are being forced to weaken their security in general, which they aren't.
I actually hope Apple loses in court, so they're forced to add true anti-rogue-signed-firmware security to future phones to keep up the fight (thus making it actually technically impossible to comply). Then its users will be safer as a result. If they'd designed the security so that it would not only protect against external attackers, but also Apple itself, then the FBI would be unable to get anything regardless of whether Apple helps or not.
The sensor will not take fingerprint scans. Having a replaced TouchID module means TouchID won't work (due to pairing failure). It'll still boot though. The old recovery mode installer just barfed on this expected condition instead of working around it like the regular OS does.
You jest, but they can already crack the Secure Enclave. Even if the FBI were asking them to crack a phone that actually had it, it would make no difference, because the Secure Enclave is just a security processor. It's not a tamperproof HSM and Apple can sign and load whatever code it wants into it at any time.
Pretty much every Nexus phone has had a battery that is easy to replace, for levels of easy varying from "you can do it with one hand" to "you need a fingernail and a common Philips screwdriver". Sure, the Nexus 5 and 5X batteries aren't officially "user replaceable", but they're about as hard to replace as 4 AA cells in an old toy with a battery lid with screws. It takes more effort to replace the CMOS battery in a random PC than to replace the battery in a Nexus 5 or 5X.
Only if you don't use an SSH agent. If you use an agent to store your keys, they are safe. Even if your keys leak because you're not using an agent, they can only leak in encrypted form (you use passphrases, don't you?). When the vulnerability is about to be triggered, a strange message (connection suspended, press return to resume) appears and must be dismissed (if you ^C at that point, you are safe).
In otherwords, this is a panic situation only for people using non-passphrased keys and no SSH agent. You also have to accept a prompt that is not normal and should raise red flags before the vulnerability can happen. People who fit that description probably have other security problems to worry about.
More realistically, you should patch your servers if you use any kind of SSH-based automation (e.g. where one master server uses SSH to automate tasks on slaves), since this allows an attacker to escalate from a target machine to the automation machine. But that requires first compromising the target, so it is not an emergency situation (unless your machines are already compromised and you don't know it, in which case, again, you have bigger problems).
That animated content benefits from 10-bit encoding is true. That has less to do with hard edges and more to do with banding artifacts on flat shaded areas - TFA actually goes into that, mentioning soft focus and fog as producing hard-to-encode gradients, the same kind of gradients present in many kinds of animation and which would benefit from using 10-bit mode. Hard edges do tend to be hard to encode with typical video codecs too (but 10-bit probably won't help you there).
However, My Little Pony isn't a particularly good example, because it's full of completely flat areas that are trivial to encode. It might take a higher quality setting than you might expect to look crisp, but at the end of the day, you're going to be spending fewer bits per frame on it than on The Avengers. Animation has its own set of encoding tradeoffs/challenges (which is why good encoders have presets tuned for animation).
If the camera is HTTP, just reverse-proxy it with something like nginx into HTTPS, and let it handle basic HTTP authentication. HTTPS should be as secure as most VPNs in practice, and the authentication at the proxy level stops pre-authentication exploits against the camera. Now that Let's Encrypt is a thing you can even get a real cert easily. The security company doesn't have to know that you're doing this; you give them HTTPS URL and off they go.
Yes, I was thinking of the Gameduino shield - it's completely silly. It even has a coprocessor inside the FPGA that is user-programmable and runs much faster than the Arduino. The SPI interface is a stupid bottleneck. It would make a lot more sense if they hadn't jumped on the Arduino shield bandwagon and instead had implemented it as a stand-alone product with its own CPU core (which could just as well use the Arduino libs if they'd wanted; it wouldn't require FPGA knowledge either).
Think about it - the Gameduino is the same idea as taking a modern GPU and connecting it to a 386 through the serial port.
I agree that if you're just plugging shields together and if you don't care about size or cost and if you're not building any custom electronics then the Arduino makes sense, even in production.
But really, I'm not focusing on commercial production here, I'm talking about hobbyists. Not those plugging in shields, but those designing their own. And making their own widgets using the Arduino as a base for their own custom electronics design. Often, people who are already designing their own boards, or at least doing permanent soldered together prototypes. People who by all measures are capable of throwing together a bare AVR... they just don't know it. Or people who randomly decide to make something useful and do a small run, perhaps still assembled by them but building more than a couple of units, and are too scared to learn how to route a tiny board with a micro and whatever else they need on it, because they don't realize just how easy it is. There is a very significant cargo cult culture here.
Code-wise, it is perfectly possible to use the Arduino libraries and software ecosystem with bare chips. That's also something that many people don't realize.
I'm not talking about the person who is still at the plug-shields-together stage and doesn't really know how to put more than 4 parts on a breadboard. Nor am I talking about some kind of custom solutions consultant who really doesn't care about efficiency and just wants to deliver the product ASAP with a minimum of effort and doesn't need it to be cost-optimized.
I'm talking about curious makers who start building things on top of the Arduino platform, understand basic digital electronics... but then somehow never move on from basing everything around the Arduino board, and think there is some kind of magical pixie dust in there and that running a bare chip is rocket science. Of which there unfortunately are a lot. People somehow end up doing truly interesting/novel designs that still have a "here goes the arduino" mentality as if it were some kind of religion.
So, the FPGA shield is not as stupid as it could feel.
The dumb part is that you can stick an AVR-compatible core in the FPGA itself and skip the Arduino. Basically, an FPGA shield for an Arduino makes no sense when you could have a standalone FPGA board that is also Arduino-compatible by virtue of embedding an Arduino clone inside the FPGA itself. That would be a much better way of jumping on the bandwagon without doing something that is, design-wise, completely silly. It would run faster than a real AVR too.
Even if you can program a microcontroller in assembler, using direct port access, don't forget that not everyone can/want to do it. Arduino is often used by people who can barely program but need some way to sequence things (artists for example).
There's a threshold here. If you're using Arduino + off-the-shelf shields as a platform and not actually learning electronics, that's fine. That's a different story. Nobody expects you to roll your own board if you care more about the software or artistic side and don't care about the hardware.
But if you're using an Arduino and building your own designs around it, i.e. understand how to use the "black box" that is the Arduino and how to interface with it, then you really need to stop thinking about it as a black box and realize that you can just as well build your own design around a microcontroller, possibly the same one and using the same exact software initially. And then you have many more possibilities than you did when you were limiting yourself to off-the-shelf devboards.
Someone who makes a led blink under arduino has learned the basics of loop and sequence of instructions... Shields and other will help to go further...
Nothing wrong with that either. Again, to clarify, I'm talking about people who inexplicably learn enough about electronics to make their own designs around the Arduino yet refuse to ever touch a bare microcontroller for some reason, or anything that doesn't have the Arduino label on it. If you're just using off the shelf blocks and focusing on the software or using it as a beginner's learning tool then there is nothing wrong with that. I'm not saying Arduino should cease to exist or has no purpose. I'm saying there is a sizable segment of the maker community who inexplicably revere it like it's the be-all-end-all of hobby electronics and don't understand just how irrelevant it becomes after you learn the very basics of building your own hardware.
But it's also true that the number of available chips is huge and selecting one may feel difficult (mostly when only basic functionalities are needed) So I can understand that people will end up stocking one or two "generic" models and stick to them.
I was in that situation too, using the 16F84. And then one day I figured out that I could literally just go to the Microchip parts selector, plug in what features I needed, and pick the cheapest chip that fit the bill (or throw a few more things in just in case). I think one thing that is sorely lacking is documentation/tutorials on "from-scratch" circuit design - such as how to select a microcontroller from the thousands available.
But there is also the fact that the authors of learning material need to stop sticking to ancient crap. For example, the PIC16F88 was a fine replacement for the PIC16F84 when it came out (2003), with a lot more features in the same form factor for cheaper. There was literally no excuse to use the 16F84 ever in any new design or new educational material after that (there were other chips before it that fit the bill too, that's just the one that comes to mind and one that I used a lot myself). The people building the tools, devkits, and writing the docs need to start actually using devices that are current as of the time they make their design.
Now, sticking to families that you know is more reasonable, because there are many unk
I don't see anything wrong with a USB HID interface for NES controllers. That's pretty much what AVR-style micros are just right for. Assuming you're using an AVR board with a native USB uC of course, like a Teensy++ or similar. I've done similar things myself, both using custom PIC designs and off the shelf AVR breakout boards. Also, LUFA, which I assume you're using, is great and in general much higher quality code than a lot of Arduino stuff.
If you're using software/bit-banged USB, you really should look into doing it right with a micro that has built-in USB. But that's by no means the worst micro abuse I've seen (and there is actually an argument for doing bit-banged low-speed USB in super low cost scenarios).
Similarly, although I'm not a huge fan of the Raspberry Pi for other unrelated reasons, it's a perfectly fine fit for NES emulation.
Further, another micro for power management isn't too far off either. It's separate enough that I wouldn't want to throw it onto the micro doing HID. I would encourage you to eventually design a more integrated power control board without using a full-blown arduino for it though, and learn to do it using MOSFETs and the like instead of relays, but that's a learning path. I've used my share of relays for quick and dirty power control.
The abuses that I had in mind are nothing like that. It's things like people using an Arduino to run game logic for a video engine implemented in an FPGA (where they could just implement the micro itself in the FPGA and get something much faster than the Arduino without the Arduino), or, on the other end of the spectrum, people using more than one Arduino to do what is effectively blink LEDs (as a one-off/temporary project it's fine, but if you're doing more than one or doing it permanently you really should stop being scared of using bare microcontrollers and learn how to make your own design closer to the requirements - an Arduino is nothing more than a voltage regulator, a USB to serial bridge chip, and a bunch of wires). Or people building entire commercial products around Arduinos with no particular excuse for using them (like compatibility with other projects/modularity), just because they don't know any better and they are too scared to stick a bare chip on a breadboard.
Yes. I'd probably consider 10 or maybe even 20 to be the cut-off for putting more effort into it.
This tells me that you have the right idea, you just need to get over the mental barrier. I deliberately made the threshold low because it really is stupidly easy to use bare chips. An Arduino is nothing more than an AVR with pins broken out, a voltage regulator, and a USB-to-TTL-serial converter onboard. You can get exactly the same effect by sticking an AVR into a breadboard with a 7805, and an external USB to TTL dongle/breakout board. And since for a great many projects you don't need USB, you can keep that external as a debugging aid only. Voila, welcome to the most basic microcontroller circuit: power and ground. You literally don't need anything else (an external clock crystal is helpful for clock accuracy but not required for many applications).
Personally, my threshold is 1. I will use dev boards for microcontroller design prototyping but if I'm ever making more than one, even for myself, I'll roll my own thing. Sometimes I don't even bother prototyping it with a dev board and go straight to a quick and dirty but stripboard build or similar, if it's a one-off but so simple that I know it will work. I mean, why use a clunky Arduino or other dev board when all I really need is an 8-pin chip for a tiny task?
This question is shit. How many more? 50? 500? It doesn't make sense to actually design your own circuit until the number gets up there someplace. Certainly at 5 I would just buy the Arduinos.
I would do my own design at 2. Sometimes at 1.
What you and the people with this problem don't realize is that it's downright trivial to stick the same micro that's on the arduino on a broadboard, give it 5V and ground, and it'll run. You're presumably already designing the rest of the circuit that plugs into the Arduino. Skip the damn thing and just use the chip that it contains directly! The Arduino is a trivial piece of electronics. Count the parts on it. The most complex part of it is the USB to serial converter. You should buy a bunch of those from China (that's what I do, always keep one in my backpack too), design plain TTL-serial ports into your circuits, and just use the converter when you need to talk to the chip (most designs do not need to be in constant communication with a PC to work).
Yeah, all that costs a lot more than just buying some $3 Arduino Nanos from China
No it doesn't. All it takes is to take the pins on your design that say "Arduino goes here" and instead plug in a bare AVR chip. Maybe give it a clock crystal and a voltage regulator. Suddenly, you don't need an Arduino any more. And now you have the freedom to pick a different chip model or family if it fits your design better, if you want. If you insist on treating the Arduino like a magical black box instead, you're not just throwing away money, you're refusing to learn. If curiosity got you interested in making electronics to begin with, why be scared of what's inside the box? The Arduino doesn't even have a case, it's not even hard to see that it really is just very few parts on a board!
I completely agree about the chip choice issue. At least it's not PIC16/18, which were horrible for C (especially PIC16), but the maker world really needs to move on to ARM and Cortex-M0. However, even worse than the ancient chip choice are the people blatantly abusing it to do things it's just a horrible choice for.
For the 5-100 crowd, you can get a small board with an ATMega on it, which costs less and takes up a lot less space in your project.
The thing is at that point you might as well use the bare chip! I really don't get this attachment to the Arduino, when all it really is is a voltage regulator, a USB to TTL chip, and a bunch of traces on a board. I think there is a huge number of people that don't realize that you can just take the same AVR that's on the Arduino, stick it on a breadboard, give it 5V and ground, and it'll run. Design your project with a TTL-serial port and just use an external USB UART dongle to talk to it when you need to.
There's nothing wrong with prototyping with dev boards like the Arduino, but way too many people build the things into permanent boxes or, worse, commercial products. That's not what they're intended for, or at least not what they should be intended for.
To be fair, I always had to put diodes across motors and relays when using BJTs. I'm not sure if it coupled back through the transistor or the rails, but I certainly got micro resets and crashes if I didn't. It's always a good idea regardless of what switching technology you use.
We all know Arduino makes things easy. The problem is there is a huge segment of the maker community who get all excited about the blinkenlights but have no drive to venture outside their comfort zone, and another huge segment which makes no attempt at providing the tools, know-how, or encouragement for them to do that, and instead just keeps building on the hype-du-jour even when it doesn't make sense. This is how you end up with a large chunk of the community being 10 years behind the curve, or who will keep abusing Arduinos for things they're terrible/underpowered/overkill/otherwise unsuited for because "Arduino!" (one of the worst offenders I saw was an FPGA shield - which was tens of times more powerful than the Arduino it would sit on top of).
This is not new. Arduino isn't new either, it's just the one product/community that got popular. I was programming microcontrollers on breakout boards (you know, just like the Arduino) with built in ISP programmers (you know, just like the Arduino, except we didn't have bootloaders back then) back when these things still connected via parallel port. And the problem was still there. Everyone was learning the PIC16F84 because that's what everyone knew, even though it was grossly out of date, and you could buy a newer chip with dozens of new features, many times the memory, for less money, in a pin-compatible package, almost source-compatible (all you had to do was change the processor header file and add a couple of init instructions to turn off some new features). But people still stuck to the PIC16F84, even though there is absolutely no logical reason to do so, because of momentum. And then people kept doing dumb things, like using external R-C circuits as a horrible analog to digital converter, even though pretty much any newer chip had a built-in ADC, because the PIC16F84 didn't.
Ask yourself this question: if you want to actually build 5 or more of a particular project, would you just get an Arduino for each? Or would you give a shot at researching the available microcontrollers, perhaps sticking to the AVR series, perhaps not, picking the right one, then making a custom board design, trying to optimize it a bit, and probably end up coming up with a much more robust, compact, and efficient design as a result, and learning a lot in the process? If your answer is the latter, then you aren't part of the problem. If your answer is the former, then you are.
I have no doubt that old-school TIP series transistors still have plenty of uses today, but the article is completely devoid of any examples. All it is saying is "look, these things aren't unusably bad for driving motors - they're just bad." Tom's post is still dead-on - using old school NPN BJTs for switching heavy loads today is completely dumb, and just because he exaggerated a bit about just how bad it can get doesn't mean he's wrong.
I was hoping for some insight, like a discussion of robustness (I've blown FETs way more easily than I've blown BJTs), or perhaps use in analog applications, or anything else really. But nope. TFA is literally just confirming the findings that it's trying to disprove, while providing absolutely no counter-examples. Somehow feels like par for the course for Hackaday these days...
I use old school jellybean parts all the time, sometimes because it really doesn't matter (driving a relay? meh, throw a BC547 on it, who cares, it's relatively low power anyway), sometimes because it's all I have lying around, but sometimes using ancient devices is actually very dumb, and I wouldn't turn a motor on and off with a BJT these days.
It *wasn't* a flaw. He didn't write an exploit, nor is this a security vulnerability. He just wrote a scraper for location metadata that was already there and was intended to be there. There is no vulnerability, just a demonstration of the extent of the data that is already normally, deliberately available. The only mention of "security" is in the Slashdot summary, which is garbage, as usual. The only thing the extension does is take location data that you can already see and plot it on a map.
The answer is that it varies - GPUs are anywhere from mediocre to useless at "normal" crypto.
It depends on whether the particular encryption algorithm/mode in use is parallelizable or not. For example, CBC is not parallelizable - you have to encrypt each block of data serially. GPUs are useless at CBC mode encryption. More modern modes like GCM and XTS are parallelizable to an extent, as you can encrypt multiple blocks at once, but there is still a serial dependency in the process (there is no real way of completely getting rid of all dependencies while keeping the algorithm usefully secure), so you still need to do some pre or post-processing of the data in a serial fashion. And even then, you're limited by bandwidth in/out of the GPU.
Public-key crypto (RSA, DSA, and ECDSA) isn't really parallelizable either as it only deals with small data sizes. And typical hash algorithms like SHA-1 and SHA-256 are also not parallelizable in their construction.
Thing is, CPUs these days have hardware AES encryption acceleration, making this mostly a moot point. GPUs are good at doing the same thing many times in parallel, which is what breaking encryption requires, but not regular usage.
Slashdot Mirror
You can simply boot into DFU mode and upload arbitrary (signed) firmware via USB that way. This is how forensics-without-Apple's-help works with iPhones that had vulnerable boot ROMs (and thus you could bypass the signature requirement). It's not that Apple has built this technology in, instead, they haven't built technology to stop this use case. The iPhone design from the very beginning included the ability to boot off of USB into a ramdisk, as this is how iTunes restores work, and by extension, that can be used to extract data and/or generally replace any behavior of the standard OS if you have Apple's keys. Regular restores using the official mechanism may or may not in practice require the PIN to work, but the underlying DFU technology allows for that kind of bypass because it doesn't have any mechanism to ensure otherwise.
This is something that I've mentioned in the past, before this debacle: that large parts of the iOS security system are just policy decisions made by their software, and that they are therefore trivially vulnerable to replacing said software - which Apple can do, as they have the keys. This allows the system to be more flexible, as it's a lot easier to write code to implement a policy than to design a cryptographic system that guarantees it.
I hope that in future iPhone versions Apple uses cryptography to secure user data in the face of unexpected updates (i.e. the requirement for a PIN is actually enforced cryptographically, and if you attempt a cold restore without the PIN you inevitably lose access to user data storage keys), but right now, that is not the case.
Android, comparatively, tends to have a weaker security system, but, on the other hand, uses "hard" crypto-based security in places where Apple doesn't. For example, iPhones use full disk encryption but it is not based on the user PIN - so, again, that's a policy system, not cryptographically guaranteed - which means that some/most data is encrypted with your PIN in newer iOS versions (at another layer), but the metadata isn't (filenames, and perhaps data that is accidentally stored without adequate file-level encryption config), and anything that isn't based on the PIN can be extracted by Apple. Android full disk encryption is cryptographically based on your PIN/passphrase (which you enter on boot), and therefore guarantees that every last bit of data and metadata is safe without depending on OS policy.
But it actually is reasonable!
The reason why Apple can be forced to unlock the iPhone in question is because current iPhone security still depends wholly on trusting Apple's firmware. They are not being asked to create a backdoor - they are being asked to exercise a backdoor that they already have. They already have the keys to the kingdom.
Now, what would be unreasonable is for the FBI to require that Apple don't actually fix this in newer iPhone iterations, thereby making it technologically impossible to comply. Which I hope they do (fix it, that is - there are technical ways of plugging this hole). But, in the meantime, this is no different from previous iOS versions where Apple willingly performed data extraction for law enforcement. The technicalities have changed, but only somewhat - Apple can still, in practice, extract all of this iPhone's data, given their master firmware signing keys. So, the only thing that has actually changed is that Apple has changed their policy to start refusing these requests.
Now, whether you believe that technology companies should be able to be compelled to help law enforcement is another matter. But, many arguments being used by the pro-Apple side (such as the "this would create a backdoor" argument) are nonsense from a technical standpoint. In practice, literally the only change of substance is that Apple is now resisting this kind of request, where they didn't in the past - and none of this has anything to do with technical security measures in iOS at all, even though Apple is trying hard to make people believe that it does (and, in some cases, actively lying about technical details).
RFC1952 clearly states that the mtime header is a POSIX timestamp, i.e., it is in universal time and not local time. The author of TFA somehow either completely missed or neglected to mention the fact that, per spec, there is no leakage of the timezone, and in fact two of his examples demonstrate exactly that.
Of the three examples cited in TFA, two of them - reddit.com and instagram.com - follow the spec and use POSIX time. Just run the php tool from TFA and you'll see that the time returned matches the current UTC time. Those servers aren't leaking their location because they follow the spec.
Only one example - bing.com - uses something other than POSIX time. Surprise surprise, some Windows-based server - presumably IIS? - ignores the standard and leaks the timezone in the process.
Now the question is, are people seriously running TOR hidden services on Windows machines? That just seems like asking for trouble. The operational security requirements of TOR hidden services are significantly higher than your average server, and I bet the chances of screwing that up with a Windows server are much higher. Leaking the timezone is probably the least of your worries in that case.
TL;DR Some Windows web server mis-implements the gzip standard and leaks the local timezone in the process. Spec-compliant web servers are not affected. TFA mis-identified two compliant servers as being affected. TFA did not list any Tor hidden services that are affected to allow for confirmation. This is mostly a non-issue.
The refusal is, to an extent, a PR stunt though. They have aided investigations (via modified firmware that can dump data) in the past. This case isn't significantly different from that, and what the FBI is asking for is, from a technical standpoint, reasonable (Apple already signs all iPhone firmwares to individual phones, so it doesn't even have a risk of compromising other users and doesn't even need a specific mechanism for that - the stuff about compromising security for everyone is FUD, because regardless of whether the FBI gets what it wants or not, the security is still fully at the mercy of Apple's bidding either way, not the FBI).
The way I see it, this is what happened: Apple used to help investigators. Then they increased the security of their platform. Then the FBI realized that they could still break in with help just as before, because in current iPhone generations anti-bruteforcing restrictions can be bypassed by modified firmware. Then Apple panicked because they don't want to go back to assisting investigations, and they've been saying that their platform is secure (without admitting that it isn't if they sign insecure firmware post-facto - it isn't secure against an attacker that colludes with -or compromises- Apple). So now they're putting up a fight, while simultaneously trying to spin it as the FBI wanting to compromise security for everyone else (it doesn't, they already have a mechanism to lock it to a given phone, this is how they stop jailbreakers from downgrading).
I don't agree with the FBI having the power to do compel Apple to do this, but so far, the only things that have changed are that Apple stopped agreeing to help, and that they claim their platform is more secure now - but it isn't, not against this particular attack. The FBI isn't asking for something radically different from what Apple used to provide, nor is it more dangerous than what Apple used to provide, it's just that Apple has done a 180 and started saying now, while wishy-washingly throwing in security implications that aren't real, trying to imply that they are being forced to weaken their security in general, which they aren't.
I actually hope Apple loses in court, so they're forced to add true anti-rogue-signed-firmware security to future phones to keep up the fight (thus making it actually technically impossible to comply). Then its users will be safer as a result. If they'd designed the security so that it would not only protect against external attackers, but also Apple itself, then the FBI would be unable to get anything regardless of whether Apple helps or not.
Uhm, no. You can just run code from RAM via DFU mode. Every jailbreaker knows this. That code can do whatever you want.
The sensor will not take fingerprint scans. Having a replaced TouchID module means TouchID won't work (due to pairing failure). It'll still boot though. The old recovery mode installer just barfed on this expected condition instead of working around it like the regular OS does.
You jest, but they can already crack the Secure Enclave. Even if the FBI were asking them to crack a phone that actually had it, it would make no difference, because the Secure Enclave is just a security processor. It's not a tamperproof HSM and Apple can sign and load whatever code it wants into it at any time.
Pretty much every Nexus phone has had a battery that is easy to replace, for levels of easy varying from "you can do it with one hand" to "you need a fingernail and a common Philips screwdriver". Sure, the Nexus 5 and 5X batteries aren't officially "user replaceable", but they're about as hard to replace as 4 AA cells in an old toy with a battery lid with screws. It takes more effort to replace the CMOS battery in a random PC than to replace the battery in a Nexus 5 or 5X.
The vulnerability is after host authentication, so that would trigger the usual host key mismatch red flags.
Only if you don't use an SSH agent. If you use an agent to store your keys, they are safe. Even if your keys leak because you're not using an agent, they can only leak in encrypted form (you use passphrases, don't you?). When the vulnerability is about to be triggered, a strange message (connection suspended, press return to resume) appears and must be dismissed (if you ^C at that point, you are safe).
In otherwords, this is a panic situation only for people using non-passphrased keys and no SSH agent. You also have to accept a prompt that is not normal and should raise red flags before the vulnerability can happen. People who fit that description probably have other security problems to worry about.
More realistically, you should patch your servers if you use any kind of SSH-based automation (e.g. where one master server uses SSH to automate tasks on slaves), since this allows an attacker to escalate from a target machine to the automation machine. But that requires first compromising the target, so it is not an emergency situation (unless your machines are already compromised and you don't know it, in which case, again, you have bigger problems).
That animated content benefits from 10-bit encoding is true. That has less to do with hard edges and more to do with banding artifacts on flat shaded areas - TFA actually goes into that, mentioning soft focus and fog as producing hard-to-encode gradients, the same kind of gradients present in many kinds of animation and which would benefit from using 10-bit mode. Hard edges do tend to be hard to encode with typical video codecs too (but 10-bit probably won't help you there).
However, My Little Pony isn't a particularly good example, because it's full of completely flat areas that are trivial to encode. It might take a higher quality setting than you might expect to look crisp, but at the end of the day, you're going to be spending fewer bits per frame on it than on The Avengers. Animation has its own set of encoding tradeoffs/challenges (which is why good encoders have presets tuned for animation).
If the camera is HTTP, just reverse-proxy it with something like nginx into HTTPS, and let it handle basic HTTP authentication. HTTPS should be as secure as most VPNs in practice, and the authentication at the proxy level stops pre-authentication exploits against the camera. Now that Let's Encrypt is a thing you can even get a real cert easily. The security company doesn't have to know that you're doing this; you give them HTTPS URL and off they go.
The thing is, it really isn't. Assuming you're wiring things up on a breadboard, what you do is:
Sure, it's a couple more steps than "Connect Arduino to USB", but it's fewer steps than the average project requires for everything else.
Yes, I was thinking of the Gameduino shield - it's completely silly. It even has a coprocessor inside the FPGA that is user-programmable and runs much faster than the Arduino. The SPI interface is a stupid bottleneck. It would make a lot more sense if they hadn't jumped on the Arduino shield bandwagon and instead had implemented it as a stand-alone product with its own CPU core (which could just as well use the Arduino libs if they'd wanted; it wouldn't require FPGA knowledge either).
Think about it - the Gameduino is the same idea as taking a modern GPU and connecting it to a 386 through the serial port.
I agree that if you're just plugging shields together and if you don't care about size or cost and if you're not building any custom electronics then the Arduino makes sense, even in production.
But really, I'm not focusing on commercial production here, I'm talking about hobbyists. Not those plugging in shields, but those designing their own. And making their own widgets using the Arduino as a base for their own custom electronics design. Often, people who are already designing their own boards, or at least doing permanent soldered together prototypes. People who by all measures are capable of throwing together a bare AVR... they just don't know it. Or people who randomly decide to make something useful and do a small run, perhaps still assembled by them but building more than a couple of units, and are too scared to learn how to route a tiny board with a micro and whatever else they need on it, because they don't realize just how easy it is. There is a very significant cargo cult culture here.
Code-wise, it is perfectly possible to use the Arduino libraries and software ecosystem with bare chips. That's also something that many people don't realize.
So what are you plugging into the Arduino?
I'm not talking about the person who is still at the plug-shields-together stage and doesn't really know how to put more than 4 parts on a breadboard. Nor am I talking about some kind of custom solutions consultant who really doesn't care about efficiency and just wants to deliver the product ASAP with a minimum of effort and doesn't need it to be cost-optimized.
I'm talking about curious makers who start building things on top of the Arduino platform, understand basic digital electronics... but then somehow never move on from basing everything around the Arduino board, and think there is some kind of magical pixie dust in there and that running a bare chip is rocket science. Of which there unfortunately are a lot. People somehow end up doing truly interesting/novel designs that still have a "here goes the arduino" mentality as if it were some kind of religion.
The dumb part is that you can stick an AVR-compatible core in the FPGA itself and skip the Arduino. Basically, an FPGA shield for an Arduino makes no sense when you could have a standalone FPGA board that is also Arduino-compatible by virtue of embedding an Arduino clone inside the FPGA itself. That would be a much better way of jumping on the bandwagon without doing something that is, design-wise, completely silly. It would run faster than a real AVR too.
There's a threshold here. If you're using Arduino + off-the-shelf shields as a platform and not actually learning electronics, that's fine. That's a different story. Nobody expects you to roll your own board if you care more about the software or artistic side and don't care about the hardware.
But if you're using an Arduino and building your own designs around it, i.e. understand how to use the "black box" that is the Arduino and how to interface with it, then you really need to stop thinking about it as a black box and realize that you can just as well build your own design around a microcontroller, possibly the same one and using the same exact software initially. And then you have many more possibilities than you did when you were limiting yourself to off-the-shelf devboards.
Nothing wrong with that either. Again, to clarify, I'm talking about people who inexplicably learn enough about electronics to make their own designs around the Arduino yet refuse to ever touch a bare microcontroller for some reason, or anything that doesn't have the Arduino label on it. If you're just using off the shelf blocks and focusing on the software or using it as a beginner's learning tool then there is nothing wrong with that. I'm not saying Arduino should cease to exist or has no purpose. I'm saying there is a sizable segment of the maker community who inexplicably revere it like it's the be-all-end-all of hobby electronics and don't understand just how irrelevant it becomes after you learn the very basics of building your own hardware.
I was in that situation too, using the 16F84. And then one day I figured out that I could literally just go to the Microchip parts selector, plug in what features I needed, and pick the cheapest chip that fit the bill (or throw a few more things in just in case). I think one thing that is sorely lacking is documentation/tutorials on "from-scratch" circuit design - such as how to select a microcontroller from the thousands available.
But there is also the fact that the authors of learning material need to stop sticking to ancient crap. For example, the PIC16F88 was a fine replacement for the PIC16F84 when it came out (2003), with a lot more features in the same form factor for cheaper. There was literally no excuse to use the 16F84 ever in any new design or new educational material after that (there were other chips before it that fit the bill too, that's just the one that comes to mind and one that I used a lot myself). The people building the tools, devkits, and writing the docs need to start actually using devices that are current as of the time they make their design.
Now, sticking to families that you know is more reasonable, because there are many unk
I don't see anything wrong with a USB HID interface for NES controllers. That's pretty much what AVR-style micros are just right for. Assuming you're using an AVR board with a native USB uC of course, like a Teensy++ or similar. I've done similar things myself, both using custom PIC designs and off the shelf AVR breakout boards. Also, LUFA, which I assume you're using, is great and in general much higher quality code than a lot of Arduino stuff.
If you're using software/bit-banged USB, you really should look into doing it right with a micro that has built-in USB. But that's by no means the worst micro abuse I've seen (and there is actually an argument for doing bit-banged low-speed USB in super low cost scenarios).
Similarly, although I'm not a huge fan of the Raspberry Pi for other unrelated reasons, it's a perfectly fine fit for NES emulation.
Further, another micro for power management isn't too far off either. It's separate enough that I wouldn't want to throw it onto the micro doing HID. I would encourage you to eventually design a more integrated power control board without using a full-blown arduino for it though, and learn to do it using MOSFETs and the like instead of relays, but that's a learning path. I've used my share of relays for quick and dirty power control.
The abuses that I had in mind are nothing like that. It's things like people using an Arduino to run game logic for a video engine implemented in an FPGA (where they could just implement the micro itself in the FPGA and get something much faster than the Arduino without the Arduino), or, on the other end of the spectrum, people using more than one Arduino to do what is effectively blink LEDs (as a one-off/temporary project it's fine, but if you're doing more than one or doing it permanently you really should stop being scared of using bare microcontrollers and learn how to make your own design closer to the requirements - an Arduino is nothing more than a voltage regulator, a USB to serial bridge chip, and a bunch of wires). Or people building entire commercial products around Arduinos with no particular excuse for using them (like compatibility with other projects/modularity), just because they don't know any better and they are too scared to stick a bare chip on a breadboard.
This tells me that you have the right idea, you just need to get over the mental barrier. I deliberately made the threshold low because it really is stupidly easy to use bare chips. An Arduino is nothing more than an AVR with pins broken out, a voltage regulator, and a USB-to-TTL-serial converter onboard. You can get exactly the same effect by sticking an AVR into a breadboard with a 7805, and an external USB to TTL dongle/breakout board. And since for a great many projects you don't need USB, you can keep that external as a debugging aid only. Voila, welcome to the most basic microcontroller circuit: power and ground. You literally don't need anything else (an external clock crystal is helpful for clock accuracy but not required for many applications).
Personally, my threshold is 1. I will use dev boards for microcontroller design prototyping but if I'm ever making more than one, even for myself, I'll roll my own thing. Sometimes I don't even bother prototyping it with a dev board and go straight to a quick and dirty but stripboard build or similar, if it's a one-off but so simple that I know it will work. I mean, why use a clunky Arduino or other dev board when all I really need is an 8-pin chip for a tiny task?
I would do my own design at 2. Sometimes at 1.
What you and the people with this problem don't realize is that it's downright trivial to stick the same micro that's on the arduino on a broadboard, give it 5V and ground, and it'll run. You're presumably already designing the rest of the circuit that plugs into the Arduino. Skip the damn thing and just use the chip that it contains directly! The Arduino is a trivial piece of electronics. Count the parts on it. The most complex part of it is the USB to serial converter. You should buy a bunch of those from China (that's what I do, always keep one in my backpack too), design plain TTL-serial ports into your circuits, and just use the converter when you need to talk to the chip (most designs do not need to be in constant communication with a PC to work).
No it doesn't. All it takes is to take the pins on your design that say "Arduino goes here" and instead plug in a bare AVR chip. Maybe give it a clock crystal and a voltage regulator. Suddenly, you don't need an Arduino any more. And now you have the freedom to pick a different chip model or family if it fits your design better, if you want. If you insist on treating the Arduino like a magical black box instead, you're not just throwing away money, you're refusing to learn. If curiosity got you interested in making electronics to begin with, why be scared of what's inside the box? The Arduino doesn't even have a case, it's not even hard to see that it really is just very few parts on a board!
I completely agree about the chip choice issue. At least it's not PIC16/18, which were horrible for C (especially PIC16), but the maker world really needs to move on to ARM and Cortex-M0. However, even worse than the ancient chip choice are the people blatantly abusing it to do things it's just a horrible choice for.
The thing is at that point you might as well use the bare chip! I really don't get this attachment to the Arduino, when all it really is is a voltage regulator, a USB to TTL chip, and a bunch of traces on a board. I think there is a huge number of people that don't realize that you can just take the same AVR that's on the Arduino, stick it on a breadboard, give it 5V and ground, and it'll run. Design your project with a TTL-serial port and just use an external USB UART dongle to talk to it when you need to.
There's nothing wrong with prototyping with dev boards like the Arduino, but way too many people build the things into permanent boxes or, worse, commercial products. That's not what they're intended for, or at least not what they should be intended for.
To be fair, I always had to put diodes across motors and relays when using BJTs. I'm not sure if it coupled back through the transistor or the rails, but I certainly got micro resets and crashes if I didn't. It's always a good idea regardless of what switching technology you use.
We all know Arduino makes things easy. The problem is there is a huge segment of the maker community who get all excited about the blinkenlights but have no drive to venture outside their comfort zone, and another huge segment which makes no attempt at providing the tools, know-how, or encouragement for them to do that, and instead just keeps building on the hype-du-jour even when it doesn't make sense. This is how you end up with a large chunk of the community being 10 years behind the curve, or who will keep abusing Arduinos for things they're terrible/underpowered/overkill/otherwise unsuited for because "Arduino!" (one of the worst offenders I saw was an FPGA shield - which was tens of times more powerful than the Arduino it would sit on top of).
This is not new. Arduino isn't new either, it's just the one product/community that got popular. I was programming microcontrollers on breakout boards (you know, just like the Arduino) with built in ISP programmers (you know, just like the Arduino, except we didn't have bootloaders back then) back when these things still connected via parallel port. And the problem was still there. Everyone was learning the PIC16F84 because that's what everyone knew, even though it was grossly out of date, and you could buy a newer chip with dozens of new features, many times the memory, for less money, in a pin-compatible package, almost source-compatible (all you had to do was change the processor header file and add a couple of init instructions to turn off some new features). But people still stuck to the PIC16F84, even though there is absolutely no logical reason to do so, because of momentum. And then people kept doing dumb things, like using external R-C circuits as a horrible analog to digital converter, even though pretty much any newer chip had a built-in ADC, because the PIC16F84 didn't.
Ask yourself this question: if you want to actually build 5 or more of a particular project, would you just get an Arduino for each? Or would you give a shot at researching the available microcontrollers, perhaps sticking to the AVR series, perhaps not, picking the right one, then making a custom board design, trying to optimize it a bit, and probably end up coming up with a much more robust, compact, and efficient design as a result, and learning a lot in the process? If your answer is the latter, then you aren't part of the problem. If your answer is the former, then you are.
I have no doubt that old-school TIP series transistors still have plenty of uses today, but the article is completely devoid of any examples. All it is saying is "look, these things aren't unusably bad for driving motors - they're just bad." Tom's post is still dead-on - using old school NPN BJTs for switching heavy loads today is completely dumb, and just because he exaggerated a bit about just how bad it can get doesn't mean he's wrong.
I was hoping for some insight, like a discussion of robustness (I've blown FETs way more easily than I've blown BJTs), or perhaps use in analog applications, or anything else really. But nope. TFA is literally just confirming the findings that it's trying to disprove, while providing absolutely no counter-examples. Somehow feels like par for the course for Hackaday these days...
I use old school jellybean parts all the time, sometimes because it really doesn't matter (driving a relay? meh, throw a BC547 on it, who cares, it's relatively low power anyway), sometimes because it's all I have lying around, but sometimes using ancient devices is actually very dumb, and I wouldn't turn a motor on and off with a BJT these days.
It *wasn't* a flaw. He didn't write an exploit, nor is this a security vulnerability. He just wrote a scraper for location metadata that was already there and was intended to be there. There is no vulnerability, just a demonstration of the extent of the data that is already normally, deliberately available. The only mention of "security" is in the Slashdot summary, which is garbage, as usual. The only thing the extension does is take location data that you can already see and plot it on a map.
The answer is that it varies - GPUs are anywhere from mediocre to useless at "normal" crypto.
It depends on whether the particular encryption algorithm/mode in use is parallelizable or not. For example, CBC is not parallelizable - you have to encrypt each block of data serially. GPUs are useless at CBC mode encryption. More modern modes like GCM and XTS are parallelizable to an extent, as you can encrypt multiple blocks at once, but there is still a serial dependency in the process (there is no real way of completely getting rid of all dependencies while keeping the algorithm usefully secure), so you still need to do some pre or post-processing of the data in a serial fashion. And even then, you're limited by bandwidth in/out of the GPU.
Public-key crypto (RSA, DSA, and ECDSA) isn't really parallelizable either as it only deals with small data sizes. And typical hash algorithms like SHA-1 and SHA-256 are also not parallelizable in their construction.
Thing is, CPUs these days have hardware AES encryption acceleration, making this mostly a moot point. GPUs are good at doing the same thing many times in parallel, which is what breaking encryption requires, but not regular usage.