Look, I'm not saying that a circuit diagram has no copyright; the actual diagram and component layout are under copyright. However, a circuit derived from said circuit diagram doesn't necessarily. As I mentioned above, if you take a generic chip and use the reference design to build up a circuit that contains two or three other reference designs and so on (which is what the original board in the article really is), you can't really claim copyright.
No, you'll find texts arguing the difference between artistic and literary copyright. If you move the parts around on your copy, artistic copyright is no longer applicable. Literary copyright might still be relevant, but only when the design is not obvious (and those would be covered by patents if it really is novel). I found these three cases described in "Contemporary Intellectual Property: Law and Policy":
In practice, this means that if you don't patent something non-obvious, your circuit diagram only gets protected under copyright as to it's identical reproduction (artistic) or literary protection in some cases if identical components, values etc. are used. However, since most integrated circuits come with reference designs and recommended values for surrounding components, even those can invalidate any protection under literary protection. Going back to the original topic, the board in question is essentially a couple of big ICs and some connectors. There is nothing special on that board, and if you were to take the design, shift components around, change some values, etc. it would look just like any other board that were to use those three chips to do what the original board would do - just with a different layout. Because the design is trivial, any expert will say that this is how a circuit based on those components would be structured. This is why, in the legal sense of the word, copyright on the schematics gives you very little if any protection.
My company builds embedded systems. We use formal verification for critical systems (quite a few in the embedded world). We're not sitting in an ivory tower...
"On 30 November 1999, the U.S. District Court in Seattle, Washington, dismissed Mackie claims that Behringer had infringed on Mackie copyrights with its MX 8000 mixer, noting that circuit schematics are not covered by copyright laws."
If that should happen anytime soon, we're all going to be screwed. The problem is that even many cryptographers and engineers don't follow the math behind many of the post quantum secure public key cryptographic systems. There are too few people working on the problem right now, and this means less people verifying the work and finding weaknesses. My bet would be on one of the Lattice-based cryptography systems or supersingular elliptic curve isogeny cryptography for post quantum right now, but we're quite far from having these available in practical applications, let alone on something like a microcontroller for all the embedded applications...
And how are consumers supposed to identify which devices are more secure at the pre-sale stage, and which vendors take security seriously?
They can't, and I never said they could. We try to educate them. One thing we do for example is analyze potential devices for customers and figure out if there are any security issues. For example, GPS trackers that you buy cheaply on eBay or Alibaba all have major security issues. We show this to customers and have independent parties verify this before they decide to buy them. Granted, we usually don't deal with individual end users, but with re-sellers or distributors and industry, but each one of them gets the security talk.
Also in what way do you take security seriously?
Take security in mind from the start of the project. Have dedicated security and cryptography people on board (I'm a cryptographer and security researcher myself), have third party code reviews, use formal verification methods, use industry standard cryptographic routines, use strict privilege separation with e.g. an L4 kernel like Fiasco.OC, have data encrypted at every stage (in motion, at rest,...), unique cryptographic keys per device, signed binaries for remote updates, every remote command is encrypted, signed and verified on the device, every communication from the device is encrypted, signed and verified by the server, etc.
In the end, if people want to change the firmware and use their own server etc., they still can as well. It just won't talk to our servers anymore, but that is usually what the goal is and we support our customers with that. We can also support our clients to use their own servers and give best practices to secure it, and often we just develop a firmware specifically for them that adheres to the same security standards.
Frankly, I have no reason to believe that IoT device makers will ever do anything to make their devices secure. We'll be seeing this shit 10 years from now, only worse.
As someone who owns a company that makes IoT devices and properly secures them, there are companies that do take security serious. The problem is that security is all too often seen as just a cost, not a feature you can charge money for. You need dedicated security people, incorporate security form the start, etc. and lots of companies just don't want or have the money. It makes the cost of the device go up, you get longer time to market, etc. and that's a hard sell to investors.
We actively try to educate on security, but it is going to take several more of these and some big losses before the majority will take security serious.
You don't need a very big battery. You just power down for most of the time. Wake up once in a while (daily or even less). Try to get a connection. No connection? Probably at sea, so power down. Keep trying until you get a connection and update your location. You don't need to know the exact route - just the starting point and the end point (maybe a few extra once you are on land again). It really doesn't need a huge battery at all; the one they show in the picture even seem rather large for this.
To give you an idea, we can send thousands of GPS locations over a cellular network with a tiny 1000mAh battery. We have some heavy duty batteries that can go up to 10 times that capacity to actively track assets for months on end at very frequent intervals. Putting a 10Ah battery like that and using infrequent updates can last for a year easily.
I meant that taking the 120V RMS value and multiplying it by sqrt(2) gives you the peak value of 170V. Slashdot ate the sqrt, and yes, that sentence could have been more clearly stated...
It is not a fact. RMS can be calculated from the peak value of the mains voltage; e.g. in the USA is about 120 × 2, or about 170 volts. But that's besides the point. Take the RMS value and an equivalent DC voltage of also 170 volts. Because the impedance of the body is frequency dependent (The body is not a resistive load. That's why we call it an impedance), the current generated by the AC voltage is higher than the DC voltage and (leaving off ventricular fibrillation) will be more dangerous. This is also why 'safe' values for DC are higher than AC.
Of course it is about reacting. Your muscles can not react faster than 0.07 seconds or so. Considering 50 HZ AC, it would cross through zero crossing twice in one period. One period is of time period 0.02 seconds, hence it passes through zero mark every 0.01 seconds. Why I brought that up? Because you wrote "DC can be much more deadly at lower voltages than AC. The main reason is that AC current goes to zero twice per second, while DC is full current at a constant rate." It's a lot more than twice per second for one.
That's a myth, and one that is perpetuated every time this topic comes up. Let's leave aside that your muscles wouldn't be able to react fast enough to make use of the AC current going through zero at 50 or 60 Hz.
The total impedance of the human body is higher for DC and decreases when the frequency increases (illustrated here: http://www.electroboom.com/?p=...). Since the impedance for DC is higher, the severity of electric shock is less than AC. Ventricular fibrillation (https://en.wikipedia.org/wiki/Ventricular_fibrillation) is considered to be the main cause of death by electric shock. The probability of a human suffering from ventricular fibrillation is much higher in the case of AC than DC.
The let-go current is an experimental measure we have of the effect of electricity on humans. The let-go current is the lowest level of current passing through a human subject through an electrode held in the hand that makes the subject unable to open his hand and drop the electrode. As mentioned in the IEC publication 60479 - Effects of current on human beings and livestock (https://webstore.iec.ch/publication/2219), letting go of parts gripped is less difficult in the case of DC.
We build M2M devices, usually using low power micro controllers (read: no Linux, no SSH). However, each device has a unique 256 bit AES key to encrypt its data (that's every single device, not product). The key is generated when the micro controller is flashed on the production line in a fully automated fashion. If you integrate it into the production line like this it's just like adding a test point along the way.
Fair enough. My experience with the former comes from even e.g. businesses we write software or make hardware for which often want completely useless features because they look cool. I'm sure the latter dwarfs the first in absolute numbers.
There is a large group of consumers that actually do want a lot of those silly things. Just look at some of the Kickstarter projects that are out there, or some of the IoT stuff that people want for example (Internet connected light bulb anyone?), or people who buy new phones as soon as a new model comes out jut because it's the new model with cool new features. Of course, I agree that there is also disconnect between what consumers want and what a company thinks they want as well. It's both.
I guess it depends on your school. I used to teach security aspects (with programming and others such as embedded systems) both at Bachelor and Master levels....
Its' not the engineers that think that. It's their managers and the marketing department: new cool features can be charged for and gives a competitive edge, because that's what your average consumer wants. In contrast, security is seen as a cost. You need dedicated people for security, code review, etc. and all of that costs money. It can delay a product. It can make the product more expensive. This is counter to what the consumer wants: cools stuff as cheap as possible. This is why security sucks.
Incidentally, part of the blame here lies with the consumer. With the pressure to go cheaper and cheaper, corners are cut, manufacturing is moved overseas, coding and engineering are outsourced to copy-paste OEMs, all in the name of making things as cheap as possible. Then, that same consumer complains that jobs are taken away. Not saying this is the only reason (profit being the obvious other one), but it does have an impact. This all in the end means security is seen as not important, so no one cares.
You can't compare arbitrary pointers in this case. You would have to cast them to integers (e.g., unsigned long) first and do the comparison there. Basically, the workflow is a) cast source and destination to long integers, b) compare if they overlap (dst - src >= len) and if so do a forward copy, otherwise a backward copy. The reason for not using a backward copy in all cases has to do with a speed penalty (for preserving alignment).
Same here. I see the same things. We design everything with security in mind from the get-go. However, this has meant having to skip customers who just didn't care (and wouldn't cover the costs that come with it). Most businesses wouldn't do that, so this all leads to horribly insecure crap.
http://www.st.com/web/catalog/... Cost: 10 Euro. That gives you an ARM Cortex with plenty of resources, Arduino compatible headers, debugger on board, and the tools are free and you can use http://www.mbed.org/ with it. And yes, the pins are labeled.
http://www.st.com/web/catalog/... Cost: 10 Euro. That gives you an ARM Cortex with plenty of resources, Arduino compatible headers, debugger on board, and the tools are free and you can use http://mbed.org/ with it.
Slashdot Mirror
In addition to a reply I gave to AC above, this provides some additional reading: https://cases.legal/en/act-uk2...
Look, I'm not saying that a circuit diagram has no copyright; the actual diagram and component layout are under copyright. However, a circuit derived from said circuit diagram doesn't necessarily. As I mentioned above, if you take a generic chip and use the reference design to build up a circuit that contains two or three other reference designs and so on (which is what the original board in the article really is), you can't really claim copyright.
No, you'll find texts arguing the difference between artistic and literary copyright. If you move the parts around on your copy, artistic copyright is no longer applicable. Literary copyright might still be relevant, but only when the design is not obvious (and those would be covered by patents if it really is novel). I found these three cases described in "Contemporary Intellectual Property: Law and Policy":
https://books.google.fi/books?...
In practice, this means that if you don't patent something non-obvious, your circuit diagram only gets protected under copyright as to it's identical reproduction (artistic) or literary protection in some cases if identical components, values etc. are used. However, since most integrated circuits come with reference designs and recommended values for surrounding components, even those can invalidate any protection under literary protection. Going back to the original topic, the board in question is essentially a couple of big ICs and some connectors. There is nothing special on that board, and if you were to take the design, shift components around, change some values, etc. it would look just like any other board that were to use those three chips to do what the original board would do - just with a different layout. Because the design is trivial, any expert will say that this is how a circuit based on those components would be structured. This is why, in the legal sense of the word, copyright on the schematics gives you very little if any protection.
My company builds embedded systems. We use formal verification for critical systems (quite a few in the embedded world). We're not sitting in an ivory tower...
"On 30 November 1999, the U.S. District Court in Seattle, Washington, dismissed Mackie claims that Behringer had infringed on Mackie copyrights with its MX 8000 mixer, noting that circuit schematics are not covered by copyright laws."
https://en.wikipedia.org/wiki/...
If that should happen anytime soon, we're all going to be screwed. The problem is that even many cryptographers and engineers don't follow the math behind many of the post quantum secure public key cryptographic systems. There are too few people working on the problem right now, and this means less people verifying the work and finding weaknesses. My bet would be on one of the Lattice-based cryptography systems or supersingular elliptic curve isogeny cryptography for post quantum right now, but we're quite far from having these available in practical applications, let alone on something like a microcontroller for all the embedded applications...
And how are consumers supposed to identify which devices are more secure at the pre-sale stage, and which vendors take security seriously?
They can't, and I never said they could. We try to educate them. One thing we do for example is analyze potential devices for customers and figure out if there are any security issues. For example, GPS trackers that you buy cheaply on eBay or Alibaba all have major security issues. We show this to customers and have independent parties verify this before they decide to buy them. Granted, we usually don't deal with individual end users, but with re-sellers or distributors and industry, but each one of them gets the security talk.
Also in what way do you take security seriously?
Take security in mind from the start of the project. Have dedicated security and cryptography people on board (I'm a cryptographer and security researcher myself), have third party code reviews, use formal verification methods, use industry standard cryptographic routines, use strict privilege separation with e.g. an L4 kernel like Fiasco.OC, have data encrypted at every stage (in motion, at rest, ...), unique cryptographic keys per device, signed binaries for remote updates, every remote command is encrypted, signed and verified on the device, every communication from the device is encrypted, signed and verified by the server, etc.
In the end, if people want to change the firmware and use their own server etc., they still can as well. It just won't talk to our servers anymore, but that is usually what the goal is and we support our customers with that. We can also support our clients to use their own servers and give best practices to secure it, and often we just develop a firmware specifically for them that adheres to the same security standards.
Frankly, I have no reason to believe that IoT device makers will ever do anything to make their devices secure. We'll be seeing this shit 10 years from now, only worse.
As someone who owns a company that makes IoT devices and properly secures them, there are companies that do take security serious. The problem is that security is all too often seen as just a cost, not a feature you can charge money for. You need dedicated security people, incorporate security form the start, etc. and lots of companies just don't want or have the money. It makes the cost of the device go up, you get longer time to market, etc. and that's a hard sell to investors.
We actively try to educate on security, but it is going to take several more of these and some big losses before the majority will take security serious.
His covert devices suck. We do twice a day updates on a 2000mAh battery for months at a time...
Disclaimer: we build GPS trackers.
You don't need a very big battery. You just power down for most of the time. Wake up once in a while (daily or even less). Try to get a connection. No connection? Probably at sea, so power down. Keep trying until you get a connection and update your location. You don't need to know the exact route - just the starting point and the end point (maybe a few extra once you are on land again). It really doesn't need a huge battery at all; the one they show in the picture even seem rather large for this.
To give you an idea, we can send thousands of GPS locations over a cellular network with a tiny 1000mAh battery. We have some heavy duty batteries that can go up to 10 times that capacity to actively track assets for months on end at very frequent intervals. Putting a 10Ah battery like that and using infrequent updates can last for a year easily.
I meant that taking the 120V RMS value and multiplying it by sqrt(2) gives you the peak value of 170V. Slashdot ate the sqrt, and yes, that sentence could have been more clearly stated...
Also, arcing: to bridge 1 cm of air with an arc you need 30KV. At that point, the arc is the least of your worries be it AC or DC.
It is not a fact. RMS can be calculated from the peak value of the mains voltage; e.g. in the USA is about 120 × 2, or about 170 volts. But that's besides the point. Take the RMS value and an equivalent DC voltage of also 170 volts. Because the impedance of the body is frequency dependent (The body is not a resistive load. That's why we call it an impedance), the current generated by the AC voltage is higher than the DC voltage and (leaving off ventricular fibrillation) will be more dangerous. This is also why 'safe' values for DC are higher than AC.
Of course it is about reacting. Your muscles can not react faster than 0.07 seconds or so. Considering 50 HZ AC, it would cross through zero crossing twice in one period. One period is of time period 0.02 seconds, hence it passes through zero mark every 0.01 seconds. Why I brought that up? Because you wrote "DC can be much more deadly at lower voltages than AC. The main reason is that AC current goes to zero twice per second, while DC is full current at a constant rate." It's a lot more than twice per second for one.
That's a myth, and one that is perpetuated every time this topic comes up. Let's leave aside that your muscles wouldn't be able to react fast enough to make use of the AC current going through zero at 50 or 60 Hz.
The total impedance of the human body is higher for DC and decreases when the frequency increases (illustrated here: http://www.electroboom.com/?p=...). Since the impedance for DC is higher, the severity of electric shock is less than AC. Ventricular fibrillation (https://en.wikipedia.org/wiki/Ventricular_fibrillation) is considered to be the main cause of death by electric shock. The probability of a human suffering from ventricular fibrillation is much higher in the case of AC than DC.
The let-go current is an experimental measure we have of the effect of electricity on humans. The let-go current is the lowest level of current passing through a human subject through an electrode held in the hand that makes the subject unable to open his hand and drop the electrode. As mentioned in the IEC publication 60479 - Effects of current on human beings and livestock (https://webstore.iec.ch/publication/2219), letting go of parts gripped is less difficult in the case of DC.
We build M2M devices, usually using low power micro controllers (read: no Linux, no SSH). However, each device has a unique 256 bit AES key to encrypt its data (that's every single device, not product). The key is generated when the micro controller is flashed on the production line in a fully automated fashion. If you integrate it into the production line like this it's just like adding a test point along the way.
Fair enough. My experience with the former comes from even e.g. businesses we write software or make hardware for which often want completely useless features because they look cool. I'm sure the latter dwarfs the first in absolute numbers.
There is a large group of consumers that actually do want a lot of those silly things. Just look at some of the Kickstarter projects that are out there, or some of the IoT stuff that people want for example (Internet connected light bulb anyone?), or people who buy new phones as soon as a new model comes out jut because it's the new model with cool new features. Of course, I agree that there is also disconnect between what consumers want and what a company thinks they want as well. It's both.
I guess it depends on your school. I used to teach security aspects (with programming and others such as embedded systems) both at Bachelor and Master levels....
Its' not the engineers that think that. It's their managers and the marketing department: new cool features can be charged for and gives a competitive edge, because that's what your average consumer wants. In contrast, security is seen as a cost. You need dedicated people for security, code review, etc. and all of that costs money. It can delay a product. It can make the product more expensive. This is counter to what the consumer wants: cools stuff as cheap as possible. This is why security sucks.
Incidentally, part of the blame here lies with the consumer. With the pressure to go cheaper and cheaper, corners are cut, manufacturing is moved overseas, coding and engineering are outsourced to copy-paste OEMs, all in the name of making things as cheap as possible. Then, that same consumer complains that jobs are taken away. Not saying this is the only reason (profit being the obvious other one), but it does have an impact. This all in the end means security is seen as not important, so no one cares.
I thought that was self evident and didn't add that...
That should of course be "compare if they overlap (dst - src >= len) and if not do a forward copy, otherwise a backward copy"
You can't compare arbitrary pointers in this case. You would have to cast them to integers (e.g., unsigned long) first and do the comparison there. Basically, the workflow is a) cast source and destination to long integers, b) compare if they overlap (dst - src >= len) and if so do a forward copy, otherwise a backward copy. The reason for not using a backward copy in all cases has to do with a speed penalty (for preserving alignment).
~ $ pwgen -y -s 20
Same here. I see the same things. We design everything with security in mind from the get-go. However, this has meant having to skip customers who just didn't care (and wouldn't cover the costs that come with it). Most businesses wouldn't do that, so this all leads to horribly insecure crap.
http://www.st.com/web/catalog/... Cost: 10 Euro. That gives you an ARM Cortex with plenty of resources, Arduino compatible headers, debugger on board, and the tools are free and you can use http://www.mbed.org/ with it. And yes, the pins are labeled.
http://www.st.com/web/catalog/... Cost: 10 Euro. That gives you an ARM Cortex with plenty of resources, Arduino compatible headers, debugger on board, and the tools are free and you can use http://mbed.org/ with it.