More like, "they want to do something else, and need the old firmware in order to do it." Why should we care about copyright if the copyright holder is not even bothering to distribute the work in question?
The calculators are locked down and check digital signatures on software, hence the problem. It is not just that the new software is missing features; the calculator is designed to stop you from adding those features on your own. Avoiding the new firmware is fine, but when someone buys a new TI calculator, it is going to come with the new firmware.
Because they want the features that the out of date software provides? Because TI is not distributing it?
Yeah yeah, copyright, and TI should be deified for having created some software and if they say you can't have it, you can't, even if all your friends do.
You can load up the calculators with textbooks and example problems, or programs that show you step-by-step methods of solving certain classes of problems (not kidding, I saw such a program implemented in Python once).
Look, I agree completely: don't allow calculators. The problem is that you then have to change the entire curriculum around. For example, a typical physics problem will involve computing a few sines and cosines, but without a calculator, students must either:
Learn how to read trigonometric tables
Learn how to compute sines and cosines by hand
Or in other words, we have to expect our students to have a skillset that was abandoned decades ago. Worse, we may have to abandon requiring numerical answers all together, and switch to something more abstract -- the last time that was tried, it was a miserable failure (see: new math).
Or, as you mentioned, we could have the schools give students calculators. This would require a change to the education budget, since schools would become responsible for buying and maintaining calculators; in some areas, such as the city where I grew up, that would be a major expense and a difficult thing to do (politically).
As I said, I agree with you, but I see why schools are not doing these things: it is not convenient.
I graduated high school in 2005 in the USA, and graphing calculators were actually encouraged in many courses, and allowed on some standardized tests.
At the same time, people would not check the fact that some people had entire tests solved on their 48G+
I saw the same thing on the TI-83, and it was not just tests -- I saw people storing entire textbooks (which surprised me, since I thought the calculators had limited memory). Somehow, this never seemed to catch the attention of the teachers...
In this case, too much functionality would seriously hurt sales. There really is no market for graphing calculators except in school, and most schools put limits on the allowed functionality of calculators. Thus, if TI allows hackers to modify the calculators and extend the functionality, it means their calculators will be banned from education settings...and there will not be a market for them.
That was not the procedure on any of the exams I took in high school. We were not allowed graphing calculators in our math classes, but they were allowed in physics and chemistry, and there was just a casual inspection of the calculator to ensure it was not above a certain model number. Perhaps things have changed over the past 5 years?
There is a huge market for graphing calculators because of standardized tests, and those tests have specific requirements on the limits of the calculator's functionality. If you can modify the calculator's firmware, then you can make a run around those rules -- the inspections of calculators rarely involve turning the calculator on, and even if it did, it would be trivial to disguised hacked firmware. These standardized tests rely on a perception of fairness and accuracy, which creates a requirement for standard calculator firmware, which means that a major part of TI's calculator business is created by the un-hackability of their calculators.
I understand for some occasions (tests, etc) it has to be a calculator, but I doubt it would be allowed to run modified software.
Which represents a TREMENDOUS market for TI, one that they are not going to give up on so easily. You may doubt that modified software will be allowed, but nobody is looking at checksums before you enter a testing room. The assumption is that you have not modified your calculator, and if that assumption is shaken, it will mean the end of a lot of calculators for standardized tests. If I were to try to guess why TI is fighting these hackers, I would say that it is all about the standardized tests, where TI calculators are exceedingly popular.
I would say they go hand in hand. Kids just need to be outdoors more, playing with other kids -- rather than spending that time eating. Just cutting the snacks out of their diet would make a huge difference, and an easy way to do that is to just not have them stay indoors all day, with snacks readily available.
On the one hand, we can continue to encourage kids to play video games and be antisocial, and hope that games with anti-fast-food themes will out-compete games like Halo. On the other hand, we can encourage kids to not play video games, and spend their time outdoors socializing and engaging in physical activity with each other, and hope that such activity will out-compete video games. Gee, which plan is going to be more effective (not that either one will be enormously effective)?
Of course, if we devote as much effort to telling kids that hang out with each other and play outdoors as we do to telling them that there is something wrong with enjoying the effects of drugs, we will hurt the profits of the corporations that produce video games. Since "the business of the United States is business," any plan that involves hurting corporate profits is a plan that will never actually happen.
The behaviour of the CPU may change as a result of setting that flag, perhaps causing its timing to change. For instance a cache miss may (or may not) occur, or memory accesses may be reordered, or a branch might be mispredicted.
We can actually prevent cache timing attacks somewhat by aligning the flag to a cache line boundary, and writing the password exactly one byte ahead of the flag. Thus, to compare the password at all, the flag will have to be cached, and so setting/checking the flag should not create a cache miss. This assumes that the password will not be too huge (i.e. a long enough password could "wrap around" and evict the line with the flag on it), but I think that it is fairly safe to assume that passwords are not megabytes in length.
As for branch predictions, we can always use a logical OR operation. So, for example, consider this:
flag = flag | (passwd[i] - submitted[i]);
Thus we do not actually need a branch in the inner loop. Note that this is overkill in the case of a network based attack, since a branch miss will not change the total delay (in theory), but this technique is useful for systems where an attacker may have the ability to measure power consumption (branches often cause changes in the power consumption of a system; this has been used to attack embedded systems in the past).
As you stated, the implication in all of this is that authentication systems need to be carefully designed to ensure that side channels are difficult to exploit (you cannot truly remove them). Usually that is not what happens, although the most basic timing attacks such as what TFA describes and not so common anymore (since they are so basic).
It seems that the systems described in TFA were open source, and that they checked plaintext passwords. Maybe I misread something (the article is full of inaccuracies anyway; timing attacks go back much further than 25 years, and reducing the noise added by a computer network is not ground breaking at all).
The AC is correct about what? The the cost of checking an entire submitted password is somehow unacceptable, but that the cost of hashing every submitted password is acceptable? Really? You can go and try this experiment yourself: time how long it takes to hash a 50 character string, and then time how long it takes to check equality between corresponding characters of two 50 character strings. I am being generous here: 50 characters is pretty long for a password.
We are not talking about a busy wait, we are talking about a method of checking passwords that does not have an obvious and easily exploited side channel.
TENEX was found to be vulnerable to this sort of attack; you could guess a password one character, by literally measuring the delay in the password comparison (identical to TFA's attack, really).
Nevermind that hashing will take a hell of a lot longer than check the entire plaintext password. Nevermind that checking the entire plaintext password is valuable if security matters (and presumably, security is the value of hashing, unless you want to build a reverse lookup table of passwords).
but if you institute a random delay you might actually make your system more secure
Random delays are easy to filter out. In fact, given that the authors performed this attack over a network (which will add random delays anyway), you should already know that they are capable of doing that.
However, it could allow an attacker to determine some part of the hashed password, which the attacker might then be able to crack using his own computers (which can just sit there trying to crack the password without dealing with any other work). This depends on the attacker's ability to do two things:
Compute the salt; this is not trivial, and a long enough salt should make this infeasible
Compute hashes that begin with a particular sequence; this is not necessarily difficult (certainly not as difficult as computing a collision), but should not be an easy thing to do
Of course, a simpler solution that does not even require those two conditions is to have the delay from a password check be constant (for a given password). Hashing and salting should be a second line of defense, for when a user manages to download the password database.
The exact theory behind eliminating the random factor eludes me, but several smart people found a way and it's supposedly correct.
It is fairly basic and necessary to pull off the attack (i.e. because this is being done over a network). Let's simplify things and suppose that the comparison is performed bit-by-bit rather than byte-by-byte; we want to determine if a particular bit is a 0 or a 1. We'll take 1000 measurements when the bit is a 0, and 1000 when it is a 1, and then take the average of the delays in each case. Invoking the law of large numbers, we can conclude that despite random noise, the average of a large number of samples should tend towards the expected value -- effectively, the noise will be removed (or more precisely, the average value of the noise will be added to both the 0 measurement and the 1 measurement, which is no different than just having a slower computer on the other end).
Now, for this to work properly, you need a large enough number of samples. The larger the range of random delays, the larger the number of samples will have to be. This creates a fairly typical security trade-off: too large of a range, and your users will be angry because they have to wait too long to log in, and too small of a range means that attackers have an easy time cracking passwords.
A better solution is to have a constant delay for every password check, regardless of whether the password is correct.
You'd be surprised. Salting and hashing passwords seems like common practice, but most programmers have minimal security training (yes, even those programmers who implement password based authentication systems) and may fail to realize the significance of not hashing.
Now, the fact that open source projects have this problem is a bit disturbing...
Slashdot Mirror
More like, "they want to do something else, and need the old firmware in order to do it." Why should we care about copyright if the copyright holder is not even bothering to distribute the work in question?
The calculators are locked down and check digital signatures on software, hence the problem. It is not just that the new software is missing features; the calculator is designed to stop you from adding those features on your own. Avoiding the new firmware is fine, but when someone buys a new TI calculator, it is going to come with the new firmware.
Because they want the features that the out of date software provides? Because TI is not distributing it?
Yeah yeah, copyright, and TI should be deified for having created some software and if they say you can't have it, you can't, even if all your friends do.
You can load up the calculators with textbooks and example problems, or programs that show you step-by-step methods of solving certain classes of problems (not kidding, I saw such a program implemented in Python once).
Or in other words, we have to expect our students to have a skillset that was abandoned decades ago. Worse, we may have to abandon requiring numerical answers all together, and switch to something more abstract -- the last time that was tried, it was a miserable failure (see: new math).
Or, as you mentioned, we could have the schools give students calculators. This would require a change to the education budget, since schools would become responsible for buying and maintaining calculators; in some areas, such as the city where I grew up, that would be a major expense and a difficult thing to do (politically).
As I said, I agree with you, but I see why schools are not doing these things: it is not convenient.
Why should TI prevent hobbyists from running buggy or out of date software?
At the same time, people would not check the fact that some people had entire tests solved on their 48G+
I saw the same thing on the TI-83, and it was not just tests -- I saw people storing entire textbooks (which surprised me, since I thought the calculators had limited memory). Somehow, this never seemed to catch the attention of the teachers...
In this case, too much functionality would seriously hurt sales. There really is no market for graphing calculators except in school, and most schools put limits on the allowed functionality of calculators. Thus, if TI allows hackers to modify the calculators and extend the functionality, it means their calculators will be banned from education settings...and there will not be a market for them.
That was not the procedure on any of the exams I took in high school. We were not allowed graphing calculators in our math classes, but they were allowed in physics and chemistry, and there was just a casual inspection of the calculator to ensure it was not above a certain model number. Perhaps things have changed over the past 5 years?
There is a huge market for graphing calculators because of standardized tests, and those tests have specific requirements on the limits of the calculator's functionality. If you can modify the calculator's firmware, then you can make a run around those rules -- the inspections of calculators rarely involve turning the calculator on, and even if it did, it would be trivial to disguised hacked firmware. These standardized tests rely on a perception of fairness and accuracy, which creates a requirement for standard calculator firmware, which means that a major part of TI's calculator business is created by the un-hackability of their calculators.
I understand for some occasions (tests, etc) it has to be a calculator, but I doubt it would be allowed to run modified software.
Which represents a TREMENDOUS market for TI, one that they are not going to give up on so easily. You may doubt that modified software will be allowed, but nobody is looking at checksums before you enter a testing room. The assumption is that you have not modified your calculator, and if that assumption is shaken, it will mean the end of a lot of calculators for standardized tests. If I were to try to guess why TI is fighting these hackers, I would say that it is all about the standardized tests, where TI calculators are exceedingly popular.
I would say they go hand in hand. Kids just need to be outdoors more, playing with other kids -- rather than spending that time eating. Just cutting the snacks out of their diet would make a huge difference, and an easy way to do that is to just not have them stay indoors all day, with snacks readily available.
On the one hand, we can continue to encourage kids to play video games and be antisocial, and hope that games with anti-fast-food themes will out-compete games like Halo. On the other hand, we can encourage kids to not play video games, and spend their time outdoors socializing and engaging in physical activity with each other, and hope that such activity will out-compete video games. Gee, which plan is going to be more effective (not that either one will be enormously effective)?
Of course, if we devote as much effort to telling kids that hang out with each other and play outdoors as we do to telling them that there is something wrong with enjoying the effects of drugs, we will hurt the profits of the corporations that produce video games. Since "the business of the United States is business," any plan that involves hurting corporate profits is a plan that will never actually happen.
Do they think kids are that stupid?
Yes they do.
The behaviour of the CPU may change as a result of setting that flag, perhaps causing its timing to change. For instance a cache miss may (or may not) occur, or memory accesses may be reordered, or a branch might be mispredicted.
We can actually prevent cache timing attacks somewhat by aligning the flag to a cache line boundary, and writing the password exactly one byte ahead of the flag. Thus, to compare the password at all, the flag will have to be cached, and so setting/checking the flag should not create a cache miss. This assumes that the password will not be too huge (i.e. a long enough password could "wrap around" and evict the line with the flag on it), but I think that it is fairly safe to assume that passwords are not megabytes in length.
As for branch predictions, we can always use a logical OR operation. So, for example, consider this:
flag = flag | (passwd[i] - submitted[i]);
Thus we do not actually need a branch in the inner loop. Note that this is overkill in the case of a network based attack, since a branch miss will not change the total delay (in theory), but this technique is useful for systems where an attacker may have the ability to measure power consumption (branches often cause changes in the power consumption of a system; this has been used to attack embedded systems in the past).
As you stated, the implication in all of this is that authentication systems need to be carefully designed to ensure that side channels are difficult to exploit (you cannot truly remove them). Usually that is not what happens, although the most basic timing attacks such as what TFA describes and not so common anymore (since they are so basic).
It seems that the systems described in TFA were open source, and that they checked plaintext passwords. Maybe I misread something (the article is full of inaccuracies anyway; timing attacks go back much further than 25 years, and reducing the noise added by a computer network is not ground breaking at all).
The AC is correct about what? The the cost of checking an entire submitted password is somehow unacceptable, but that the cost of hashing every submitted password is acceptable? Really? You can go and try this experiment yourself: time how long it takes to hash a 50 character string, and then time how long it takes to check equality between corresponding characters of two 50 character strings. I am being generous here: 50 characters is pretty long for a password.
We are not talking about a busy wait, we are talking about a method of checking passwords that does not have an obvious and easily exploited side channel.
TENEX was found to be vulnerable to this sort of attack; you could guess a password one character, by literally measuring the delay in the password comparison (identical to TFA's attack, really).
Welcome back to the 1960s!
Nevermind that hashing will take a hell of a lot longer than check the entire plaintext password. Nevermind that checking the entire plaintext password is valuable if security matters (and presumably, security is the value of hashing, unless you want to build a reverse lookup table of passwords).
You are beginning to sounds like a troll.
but if you institute a random delay you might actually make your system more secure
Random delays are easy to filter out. In fact, given that the authors performed this attack over a network (which will add random delays anyway), you should already know that they are capable of doing that.
Of course, a simpler solution that does not even require those two conditions is to have the delay from a password check be constant (for a given password). Hashing and salting should be a second line of defense, for when a user manages to download the password database.
The exact theory behind eliminating the random factor eludes me, but several smart people found a way and it's supposedly correct.
It is fairly basic and necessary to pull off the attack (i.e. because this is being done over a network). Let's simplify things and suppose that the comparison is performed bit-by-bit rather than byte-by-byte; we want to determine if a particular bit is a 0 or a 1. We'll take 1000 measurements when the bit is a 0, and 1000 when it is a 1, and then take the average of the delays in each case. Invoking the law of large numbers, we can conclude that despite random noise, the average of a large number of samples should tend towards the expected value -- effectively, the noise will be removed (or more precisely, the average value of the noise will be added to both the 0 measurement and the 1 measurement, which is no different than just having a slower computer on the other end).
Now, for this to work properly, you need a large enough number of samples. The larger the range of random delays, the larger the number of samples will have to be. This creates a fairly typical security trade-off: too large of a range, and your users will be angry because they have to wait too long to log in, and too small of a range means that attackers have an easy time cracking passwords.
A better solution is to have a constant delay for every password check, regardless of whether the password is correct.
I presume this is the same sort of logic that lead to the decision to use plaintext passwords, rather than salted and hashed passwords.
They check the hash one character (or word, quadword, whatever) at a time.
You'd be surprised. Salting and hashing passwords seems like common practice, but most programmers have minimal security training (yes, even those programmers who implement password based authentication systems) and may fail to realize the significance of not hashing.
Now, the fact that open source projects have this problem is a bit disturbing...