GSM encryption crack made public
Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net. |
The schemes commonly used to encrypt GSM telephone calls, SMS messages, and data transmissions have been theoretically broken for years at both the protocol and cipher levels, but results presented in Berlin at the 26th Chaos Communication Congress (26C3) on December 27 demonstrate that a practical attack can be easily implemented. Researchers unveiled cracking tables requiring just two terabytes of disk space that can be used to look up a GSM encryption key and decrypt a transmission. The tables were computed on 40 commodity hardware PC nodes in just a few months' time, and are shared through Bittorrent. Furthermore, the presentation explains that the more difficult practical task of intercepting and capturing GSM calls can already be done with inexpensive radio equipment and open source software.
Background
The cipher under attack is known as A5/1; it was invented by the GSM Association in 1987. Due to the Cold War, A5/1 was deployed only in Western Europe and the United States, and was accompanied by a significantly weaker cipher called A5/2 for export to other regions. The GSM protocol supported both A5/1 and A5/2, plus A5/0, or unencrypted connections, a choice that left the protocol itself vulnerable to attack.
A5/1 was not published, but researchers began to reverse-engineer it almost immediately, work that was completed and publicized in 1999. Theoretical attacks based on weaknesses in the cipher date back to at least 1997, but real-world attacks on the system as implemented in the global GSM network only began to appear in 2003, when the team of Elad Barkan, Eli Biham, and Nathan Keller reported that phones use the same set of keys regardless of whether A5/1 or A5/2 encryption was enabled. [PULL QUOTE: Thus, by momentarily tricking a phone into using A5/2 (which can be cracked in seconds), a man-in-the-middle attacker can retrieve the session key for a call and continue to decrypt it even if it subsequently switches to A5/1 at the network's request. END QUOTE] Thus, by momentarily tricking a phone into using A5/2 (which can be cracked in seconds), a man-in-the-middle attacker can retrieve the session key for a call and continue to decrypt it even if it subsequently switches to A5/1 at the network's request. Shortly thereafter, networks were advised to discontinue use of A5/2.
Barkan, Biham, and Keller also published a ciphertext-only attack on A5/1 itself that relied on a time-memory tradeoff: building a lookup table of partially-precomputed hash values. A5/1 uses a 64-bit key (although, interestingly enough, 10 bits are fixed at 0 in all known deployments, making the practical strength 54-bits), which would require around 128 petabytes for a complete code book (a complete plaintext:ciphertext table for each key).
In 2008, a group called The Hackers Choice (THC) announced that it had computed the complete code book, in a more space-efficient format that required just three terabytes, running on a cluster of 70 field-programmable gate array (FPGA) boards. THC did not publish its tables, however.
A5/1 Security Project, technique and results
At the Hacking at Random conference in July of 2009, researchers Karsten Nohl and Sascha Krißler announced yet another effort to compute the code book, dubbed the A5/1 Security Project, utilizing distributed computing with publicly available source code. The A5/1 Security Project code was designed to run on NVIDIA and ATI graphics cards using the CUDA parallelization architecture; a participating node would claim a unique chunk of the code book from the project, then report its results back to the centralized server.
Nohl and Chris Paget announced in their 26C3 presentation that the project had completed computation of the tables, and that the complete result was available on Bittorrent. Around 40 nodes participated in the effort over three months; some false starts caused by bugs in the code slowed down the computation initially, but the results as presented at 26C3 are final. The format chosen by the project uses a combination of rainbow tables and distinguished point tables as a space-saving measure.
Rather than storing the entire code book as a plaintext:ciphertext lookup table, rainbow tables compute chains of encrypted values, and store only the first and last values in the chain. Decrypting a given value then involves generating a chain from the value, and looking at each step for a match in the rainbow table. Thus, using longer chains in the rainbow table requires less storage space, but demands more time in the decryption step by requiring more computation steps looking for a match. But once a match has been found, the key can then be determined allowing further decryption using the algorithm directly.
Distinguished point tables save space by selectively storing only those chains in the table that have an endpoint matching some helpful property — such as a long string of zero-bits. Chains that don't have that property are not stored saving a great deal of space, but turn the key extraction into a probabilistic search. Given enough ciphertext, though, key extraction should be possible.
The team eventually settled on a combined table approach that used 380 tables, each of which consists of 32 distinguished-point segments of length 2^15 merged into one rainbow table. In addition, they discovered ways to locate known plaintext in a GSM transmission (such as predictable ACK packets) that would save time and space by requiring a smaller subset of the code book to be computed. If those details do not communicate much to non-cryptographers, the practical results should: the final tables take up just 2 terabytes of storage space, and can be used to perform near-real-time decryption.
Reaction and better security
Nohl and Paget are quick to point out that the completion of the A5/1 tables itself does not constitute a measure for intercepting and listening in on GSM telephone calls. Shortly after news of the work went public, the GSM Association issued a press release playing down the result, based in large part on what it called the "practical complexity" of capturing and recording a GSM call.
Nohl and Paget dealt with that assertion in their talk, describing the components that would be required to receive, process, and record GSM calls, all of which are easy to obtain. At the hardware level, the Universal Software Radio Peripheral (USRP) developed for the GNU Radio project can tune and capture GSM spectrum. The OpenBTS software stack implements GSM and is designed for use with USRP, allowing the user to process and decode the data in a GSM channel, as well as to perform other feats in active attacks, such as faking a legitimate GSM base station. Other software packages, such as OpenBSC and Airprobe, can also be used for specific GSM-related tasks.
The GSM Association press release also implies that any real-world risk inherent in a broken A5/1 is moot because the stronger A5/3 is also available, and is not subject to the same algorithmic attacks. Nohl and Paget point out, however, that theoretical attacks on A5/3 have already been published, and that, despite its availability for over a decade, no carriers use it.
Moreover, the GSM protocol itself is still highly insecure; in fact the same technique Barkan, Biham, and Keller used in 2003 to trick a phone into downgrading from A5/1 to A5/2 can also be used to attack A5/3 — since A5/3 uses the same encryption keys as A5/1 and A5/2. In addition, lack of network authentication and the fact that GSM phones automatically attach to the strongest available base station make interception and man-in-the-middle attacks possible, that are independent of the encryption method deployed.
Securing mobile phone communications is vital in today's world. As Nohl and Paget's presentation noted, GSM is not only used for voice calls, but for SMS (which increasingly includes financial transactions) and EDGE data connections as well. Consumers have no control over the GSM network, and although most have little to worry about in the realm of criminal attackers intercepting their voice calls, business and government users do. 40 off-the-shelf graphics cards computed the A5/1 code book in less than three months; the estimated hardware needed to built a USRP-based GSM interceptor is less than US$3000. That is a trivial investment to anyone with a financial interest in eavesdropping. On top of that, as the weakness of WEP encryption demonstrated to WiFi router owners, a broken security system leaves the network open to mischief, bandwidth-theft, and other security problems beyond call interception. Hopefully, as the A5/1 Security Project suggests, the telecommunications sector will now take positive steps to correct the flaws in GSM and implement better security.
For the open source software community, however, there is another benefit to the project's success: the basic idea is reusable. The team built the distributed pre-computation framework to be generic; it can work on any cipher, with different table layouts, and on multiple hardware back-ends. In other words, if you have a cipher that needs a code book and you have access to 40 modern graphics cards, your job may have just gotten a lot easier.
Index entries for this article | |
---|---|
Security | Encryption/Mobile phone |
Security | Mobile phones |
GuestArticles | Willis, Nathan |
(Log in to post comments)
GSM encryption crack made public
Posted Jan 6, 2010 21:15 UTC (Wed) by Baylink (guest, #755) [Link]
The "why didn't you tell the carriers first" anti-full-disclosure noise on this one is giving me hives, all the moreso since *they did*. If I've known it was cracked for 4 years, and the carriers didn't, they all need to fire their chief engineers on the spot.
GSM encryption crack made public
Posted Jan 7, 2010 2:41 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
GSM encryption crack made public
Posted Jan 7, 2010 15:10 UTC (Thu) by Baylink (guest, #755) [Link]
My assertion stands. :-)
UMTS
Posted Jan 6, 2010 22:06 UTC (Wed) by bojan (subscriber, #14302) [Link]
UMTS
Posted Jan 6, 2010 22:52 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
With UMTS, the cell phone again went down the I'll-roll-my-own-damn-encryption route, and used a new block cipher called KASUMI. It's more secure that the utterly broken plain GSM system, but it's still suspect: KASUMI has a 64-bit block size and takes 128-bit keys (which other modern ciphers have 128-bit blocks and use keys that start at 128 bits). There already has attacks against the cipher, though these attacks aren't yet practical.When designing a cryptosystem, just use the standards; go with AES and other time-tested algorithms. It's very easy to get cryptography subtly and catastrophically wrong.
UMTS
Posted Jan 6, 2010 23:06 UTC (Wed) by bojan (subscriber, #14302) [Link]
Hopefully with smartphones becoming the norm, the systems may become even more flexible than that, where cyphers can be enabled/disabled on the fly, based on known vulnerabilities.
Thanks for the info about KASUMI.
UMTS
Posted Jan 7, 2010 15:12 UTC (Thu) by Baylink (guest, #755) [Link]
That might be possible with *content-layer* encryption, but the topic being discussed here is air-interface link-layer encryption -- without that, you might be able to keep your content private, but traffic analysis will still be possible... and that's often more useful anyway.
UMTS
Posted Jan 7, 2010 22:00 UTC (Thu) by bojan (subscriber, #14302) [Link]
UMTS
Posted Jan 8, 2010 2:18 UTC (Fri) by airlied (subscriber, #9104) [Link]
these chips generally don't have the grunt to keep multple firmwares installed.
UMTS
Posted Jan 8, 2010 2:58 UTC (Fri) by bojan (subscriber, #14302) [Link]
UMTS
Posted Jan 7, 2010 23:47 UTC (Thu) by Nimos (guest, #62863) [Link]
We are not talking about a simple web or SSH server here, but network equipment that continually encrypt/decrypts thousands of sessions simultaneously. If complicated algorithms and keys are used, the processing power would be astronomical and a pratical implementation not feasible. Processing power of mobile devices also needs to be taken into consideration although they have increased massively, but the network side often gets forgotten.
UMTS also has network authentication, integrity protection and 128 bit keys, which is also a big improvement on GSM. There is also a stronger UMTS encryption algorithm that is based on the SNOW 3G cipher, but many devices don't support this.
Interesting in LTE, the two ciphers in the stardard initially are SNOW 3G and AES.
UMTS
Posted Jan 8, 2010 13:42 UTC (Fri) by anton (subscriber, #25547) [Link]
With a well-designed protocol the content is encrypted end-to-end and the provider does not need (and ideally should not be able to) decrypt it. So the provider only needs to decrypt some meta-data, which is not that much. Also, AFAIK AES is designed (and was selected) to be cheap to encrypt and decrypt. The chances that the UMTS designers found something significantly cheaper that's as secure are very small.
UMTS
Posted Jan 8, 2010 15:08 UTC (Fri) by anselm (subscriber, #2796) [Link]
This is well and good from an end-user's point of view, but of course the last thing that mobile communications systems are supposed to do is provide arbitrary thugs with communication methods that law enforcement cannot intercept and decrypt (and free with the basic service at that). The nice thing about the present system, from the point of view of law enforcement, is that communications are only encrypted on the air, but available for interception in the clear from where they enter the backbone network.
So if the thugs want to communicate securely, they will need to provide their own end-to-end encryption, without help from the network operators. As far as the operators are concerned, this isn't a problem as long as their protocols are secure enough to prevent things that eat into their revenue, such as large-scale fraud by users impersonating others for billing purposes.
UMTS
Posted Jan 8, 2010 16:05 UTC (Fri) by anton (subscriber, #25547) [Link]
The priorities of the NSA are not necessarily the priorities of the mobile providers and their paying customers. However, the ideal of not being able to decrypt the messages in the middle with an ordinary mobile phone is probably hard to attain, because there is no end-to-end authentication, so I don't see how man-in-the-middle attacks could be detected. Hmm, the SIM cards could identify themselves, and so one could detect a change in SIM cards after the first time one has had a call to that number; so the man-in-the-middle would have to be there from the start to avoid getting noticed (but that assumes that the NSA does not have the data necessary for faking this identification). So yes, if citizens value their privacy, they have to do end-to-end encryption themselves, do their own key management, and they have to be sure they can trust their encryption device.If a provider conspires with the NSA (or similar organizations) to subvert the privacy of their paying customers, then decrypting and reencrypting the connection will be the least of the costs that is incurred in that action: They have to pay for some human or voice-recognition computer to understand what was said, and either of these options will be more expensive than decrypting and re-encrypting the connection.
Your use of "thugs" for citizens who value their privacy appears to come from the idea that innocent citizens have nothing to hide. Do you wear clothes in warm weather? Do you have curtains in your home? If yes, why? Do you have something to hide?
Why do you think that users impersonating others will eat into the provider's revenue (especially if all the providers have that problem)?
UMTS
Posted Jan 8, 2010 16:28 UTC (Fri) by anselm (subscriber, #2796) [Link]
Your use of "thugs" for citizens who value their privacy appears to come from the idea that innocent citizens have nothing to hide.
Read again. That was from the point of view of the non-endusers.
If it was up to me I'd let everybody communicate securely. However, unfortunately neither the government nor the mobile operators have seen fit to consult me for my opinion. Quite on the contrary -- over here in Europe they're busy building a large infrastructure based on the assumption that everybody is a potential criminal, hence everyone's use of telecomms (phone calls, SMS, e-mail, ...) must be monitored and stored for an extended period of time for the benefit of the police and assorted three-letter agencies. It was all the German Constitutional Court could do to keep them from exploiting the data to try to identify, e.g., traffic transgressors and Internet downloaders here in Germany, pending a more thorough judicial review.
UMTS
Posted Jan 11, 2010 12:17 UTC (Mon) by marcH (subscriber, #57642) [Link]
This is only one type of interceptions the NSA might be interested in. But it is also also very interesting for the NSA to have weak air encryption by default, because 1) it leaves no traces at the provider, or 2) it allows eavesdropping on ANY provider, even a not friendly one. See the Crypto AG scandal for an example of what the NSA is capable of.
UMTS
Posted Jan 8, 2010 12:31 UTC (Fri) by jonth (guest, #4008) [Link]
As for "going with AES and other time-tested algorithms", history is littered with cryptographic algorithms that were considered secure, but now are not. (SHA-1 springs to mind). KASUMI was selected in the mid to late nineties, and the standard algorithms weren't used either because of licensing or implementation difficulties (on networks going live this year, KASUMI will be live on battery operated hardware at bitrates of 40Mb/s or so). I seem to recall that the selection process also occured at around the time the US considered 128bit encryption as "weapons grade," so US generated algorithms weren't exportable. At that time, MKSUMI was considered to be pretty good, and the algorithm itself is still considered secure to practical attacks.
Comparing it to modern ciphers is not a fair comparison. If you want to do that, then look at SNOW 3G (the cipher selected for LTE), and then complain.
UMTS
Posted Jan 12, 2010 16:26 UTC (Tue) by quotemstr (subscriber, #45331) [Link]
The full-round version of KASUMI was just broken with a related-key attack:In this paper we describe a new type of attack called a sandwich attack, and use it to construct a simple distinguisher for 7 of the 8 rounds of KASUMI with an amazingly high probability of 2^-14. By using this distinguisher and analyzing the single remaining round, we can derive the complete 128 bit key of the full KASUMI by using only 4 related keys, 2^26 data, 2^30 bytes of memory, and 2^32 time. These complexities are so small that we have actually simulated the attack in less than two hours on a single PC, and experimentally verified its correctness and complexity. Interestingly, neither our technique nor any other published attack can break MISTY in less than the 2^128 complexity of exhaustive search, which indicates that the changes made by the GSM Association in moving from MISTY to KASUMI resulted in a much weaker cryptosystem.Now, like I said saying, for the love of all that's good and right, just use AES.
Non-trivial choice of hardware
Posted Jan 6, 2010 22:30 UTC (Wed) by proski (subscriber, #104) [Link]
To add insult to injury, GSM was cracked by video cards!
Non-trivial choice of hardware
Posted Jan 8, 2010 14:53 UTC (Fri) by amikins (guest, #451) [Link]
GSM encryption crack made public
Posted Jan 6, 2010 23:02 UTC (Wed) by csamuel (✭ supporter ✭, #2624) [Link]
The fact that A5 was known to be weak goes back to at least 1994 as the Cambridge crypie Ross Anderson wrote on this to uk.telecom (amongst others), now archived here:
http://yarchive.net/phone/
Regarding the source of the weakness, he wrote:
Indeed, my spies inform me that there was a terrific row between the NATO signals agencies in the mid 1980's over whether GSM encryption should be strong or not. The Germans said it should be, as they shared a long border with the Evil Empire; but the other countries didn't feel this way, and the algorithm as now fielded is a French design.It's not clear here if he's talking about A5/1 or A5/2.
GSM encryption crack made public
Posted Jan 6, 2010 23:04 UTC (Wed) by csamuel (✭ supporter ✭, #2624) [Link]
Usenet posting from 1994 on A5 is:
GSM encryption crack made public
Posted Jan 7, 2010 0:42 UTC (Thu) by drag (guest, #31333) [Link]
The GSM encryption is really designed to control subscribers and not really
protect them.
Meaning that the encryption is over the air only. Once it gets to the base
station and gets turned into TCP/IP traffic then all bets are off. There is
also 50 years worth of technology laying around being used in telephone
systems with numerous built-in back doors created for monitoring calls for
law enforcement, tracking users, and all sorts of other things.
So if your paranoid and want to be safe the only thing you can do is do
encrypted VoIP AND use a phone with open firmware. VPN stuff makes it
relatively simple once you get the software and the data line to your
smartphone.
Of course the GSM encryption stuff is pathetic in how poor it is and how
old fashioned the thinking of the telephone companies are.
GSM encryption crack made public
Posted Jan 7, 2010 15:14 UTC (Thu) by Baylink (guest, #755) [Link]
And it's to protect carriers from fraud, which they will have to eat -- which is the *real* issue here. As soon as some noticeable fraudulent traffic starts eating into their revenue, there will be a fix; bet on it.
GSM encryption crack made public
Posted Jan 7, 2010 18:39 UTC (Thu) by drag (guest, #31333) [Link]
government.
GSM encryption crack made public
Posted Jan 7, 2010 18:51 UTC (Thu) by drag (guest, #31333) [Link]
Also you can't trust the government either way. If your involved in legal difficulties then what you say can easily be taken out of context and used against you. With the laws in the country so massively out of control a normal executive violates criminal federal a minimal of several times a year just doing normal business.For example; Doing something, like, transporting dentures (like what old people use in their mouths) across state lines, is a federal offense and is prosecutable with a fine and even jail.
The chances of the government picking up on something and throwing you in jail or a dishonest person in government using something against you is very likely if you do end up being a target.
So no. I definitely meant to protect yourself form your own government and from your own telco.
Not also to forget that people tend to travel and your cell phone will automatically latch onto pretty much anything. So you are very unlikely to actually know what telephone company your going through and if your travelling internationally then it can be controlled by a wide verity of different governments. If your on a business trip in Asia and your in a country like China were the government runs the businesses and they work together.. how much do you want to have to trust their infrastructure?
That is to say, if you don't care that your shit is unsafe then you shouldn't care if GSM encryption sucks. If you _DO_ care that GSM encryption sucks then you should definitely not forget that the entire infrastructure is a huge pile of crap when it comes to security.
If your going to be paranoid then you might as well do it right.
GSM encryption crack made public
Posted Jan 8, 2010 4:42 UTC (Fri) by Baylink (guest, #755) [Link]
Got it. ;-)
GSM encryption crack made public
Posted Jan 8, 2010 23:14 UTC (Fri) by njs (subscriber, #40338) [Link]
What? Really? Cite please?
Federal denture crime
Posted Jan 9, 2010 0:01 UTC (Sat) by anselm (subscriber, #2796) [Link]
That would be -- tadaa! -- the Federal Denture Act (18 USC 1821, enacted in 1942 and amended in 1996 and 2002). You may be relieved to hear that the penalty of a fine and/or one year in the federal pen applies not to your granddad crossing a state line with his dentures but specifically to people who market unlicensed dentures in interstate commerce -- where »unlicensed« means »not manufactured or legally approved by a dentist licensed to practice in the state where the dentures are being sent«. So, no false teeth on the cheap over the Internet.
Some very few US states allow »denturists« to sell dentures to the general public without the involvement of dentists, and denturists have been campaigning to be allowed to do so in other states. Dentists aren't too keen on the idea, insisting that denturists are not properly trained to diagnose (let alone treat) various diseases and complications in the mouths of their patients that would prevent dentures from being properly fitted. Considering that, in the states where it is legal, you can become a denturist after usually a mere two-year degree and a licensing exam, plus possibly an internship with another denturist, they may have a point.
Federal denture crime
Posted Jan 9, 2010 2:05 UTC (Sat) by njs (subscriber, #40338) [Link]
One could certainly argue about the fine points of profession legislation, but alas for the original poster, I don't see how this proves that the laws in the USA are "so massively out of control a normal executive violates criminal federal [law] a minimal of several times a year just doing normal business". (I can see how this might be true for copyright law, which is a particular portion of the law that is indeed massively out of control -- though even then, *criminal* violation is not *that* trivial -- but I am not sure there are any other examples.)
Federal denture crime
Posted Apr 19, 2010 7:43 UTC (Mon) by Denture (guest, #65465) [Link]
Federal denture crime
Posted Jan 2, 2021 1:48 UTC (Sat) by anselm (subscriber, #2796) [Link]
People interested in dentures law may be fascinated to find out that 18 USC §1821 has been repealed in the “Consolidated Appropriations Act of 2021”, specifically Division O, Title X, Section 1002(8), as part of a general cleanup of various oddball provisions in the U.S. Code which, for example, also decriminalises unauthorised for-profit use of the Forest Service's iconic “Smokey Bear” mascot.
This means that transporting dentures across state lines to where they haven't been prescribed by an appropriately licensed practicioner is now no longer a federal crime. We can presumably expect breakthroughs in online DIY denturistry.
Federal denture crime
Posted Jan 4, 2021 0:34 UTC (Mon) by mathstuf (subscriber, #69389) [Link]
GSM encryption crack made public
Posted Jan 8, 2010 17:59 UTC (Fri) by giraffedata (guest, #1954) [Link]
And it's to protect carriers from fraud, which they will have to eat
They won't eat it. They'll charge it to the customers (i.e. fraud increases the cost of phone service). So what we can say about encryption is that it's partly to protect the customer (from a privacy standpoint) and partly to reduce the price of the service.
Re: "They'll charge it to the customers"
Posted Jan 9, 2010 4:05 UTC (Sat) by nybble41 (subscriber, #55106) [Link]
However, rising costs do have one noticeable *indirect* effect on prices: under some conditions they can nullify the profit margins of the marginal producers, thus forcing them to go out of business and reducing the overall supply of the good. At that point prices must rise such that supply and demand regain their balance. However, the change in price is typically less than the change in cost, so the rising cost is born in part by both the producers and the consumers, not simply "passed on".
Re: "They'll charge it to the customers"
Posted Jan 9, 2010 11:43 UTC (Sat) by nix (subscriber, #2304) [Link]
Simply put, if it were possible for them to bring in more revenue by setting a higher price they would already have done so.Read Grossman & Stiglitz's _On the Impossibility of Informationally Efficient Markets_ and come back to us.
Re: "They'll charge it to the customers"
Posted Jan 9, 2010 18:13 UTC (Sat) by giraffedata (guest, #1954) [Link]
Simply put, if it were possible for them to bring in more revenue by setting a higher price they would already have done so.
But it's not possible because we have laws to prevent an industry as a whole from setting a price of its own volition.
I know why you're responding this way. It's because when someone says a company will just pass on its costs to its customers, 99% of the time he doesn't understand economics and is wrong because he's talking about a product with high elasticity of demand -- for example a product of a single producer in a competitive market. However, in this case, I know a great deal about economics and was actually talking about a product with pretty high elasticity -- wireless phone service overall. The costs of having GSM not be encrypted affects all the providers.
Certainly, the statement, "If Sprint loses this lawsuit, it will just pass the cost of the judgment on to its customers" is wrong.
Re: "They'll charge it to the customers"
Posted Jan 9, 2010 18:20 UTC (Sat) by giraffedata (guest, #1954) [Link]
Whoops, I said phone service overall has pretty high elasticity of demand; I meant low. The demand is pretty inelastic. You can raise the price of phone service (from all providers) and a lot of people will still pay it.
Re: "They'll charge it to the customers"
Posted Jan 9, 2010 18:05 UTC (Sat) by giraffedata (guest, #1954) [Link]
Everything you say is right and important, but I stand by my statement that the phone companies would pass the cost on to the customers instead of eating it.
First of all, I'm being approximate because the rise in price will not be the entire rise in cost; it will be somewhat less. This will cause there to be less phone service delivered (because some customers are priced out of the market), which will reduce costs to fill the rest of the gap.
But the more important part of my statement is that the producers won't eat the cost of fraud. It's a competitive market; the producers have no profits with which to eat it. The cost of fraud will be reflected in higher prices and less total service.
It's not true that if the industry could raise prices, it would do it even without the fraud. The competition among individual members of the industry prevents it from setting a price above cost.
Re: "They'll charge it to the customers"
Posted Jan 11, 2010 11:10 UTC (Mon) by cmccabe (guest, #60281) [Link]
Re: "They'll charge it to the customers"
Posted Jan 12, 2010 9:42 UTC (Tue) by Cato (guest, #7643) [Link]
GSM encryption crack made public
Posted Jan 7, 2010 1:05 UTC (Thu) by jimparis (guest, #38647) [Link]
GSM encryption crack made public
Posted Jan 7, 2010 6:30 UTC (Thu) by gmaxwell (guest, #30048) [Link]
There are certainly some things you can say about the difficulty of dealing with the physical layer here but anyone who would liken 2TB to 20KM of books rather than say, a $170 part from a neighbourhood electronics store, 4 hours of uncompressed 24fps 1080p RGB video, or even 50 blu-ray disks isn't really someone who's view you can trust.
GSM encryption crack made public
Posted Jan 7, 2010 20:03 UTC (Thu) by jmm82 (guest, #59425) [Link]
GSM encryption crack made public
Posted Jan 7, 2010 23:34 UTC (Thu) by gidoca (subscriber, #62438) [Link]
GSM encryption crack made public
Posted Jan 14, 2010 15:54 UTC (Thu) by pboddie (subscriber, #50784) [Link]
The point in the GSMA statement where they say "by constructing a large look-up table1 of approximately 2 Terabytes this is equivalent to the amount of data contained in a 20 kilometre high pile of books" really says it all about their response.
Yes, given the mindset of the paper pushers who run these cartels and "industry organisations", they've probably assigned someone to the job of printing the table out on the office printer.
(I noticed yet another consumer electronics "industry organisation" the other day - something to do with home networking and entertainment - and wondered what the motivations are for the same companies to set yet another one up for almost the same purpose as the last one, and the one before, other than to maybe give jobs to "the right people" or as part of some kind of "tax deduction" strategy.)
Apropros 26C3
Posted Jan 7, 2010 14:29 UTC (Thu) by meyert (subscriber, #32097) [Link]
Apropros 26C3
Posted Jan 7, 2010 23:17 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
Fixing the symptom and not the bug remains disappointingly common in the Linux kernel (and to be fair, elsewhere in software development too).
However, keep in mind that this talk insisted on repeatedly assuming that they (a hypothetical grey or black hatted individual) were doing all this because other options had failed for them. In practice on most networks those methods will work - this is a hole in a perimeter fence, but in most cases the gates are not guarded and so they don't even need a hole. So don't rush out to patch your fence unless you're one of those rare network administrators who genuinely knows the front gate is secure (in this case, that individual hardware ports are locked to specific MAC source addresses).
The 8169 bug appears to be (at least partly) hardware related. It would be interesting to see whether this is guarded against in drivers from anyone else, including the Windows drivers from the hardware vendor. The size underflow shown in passing is embarrassing, but if the hardware ought to never give zero size, it is understandable that the driver programmer doesn't check for that.
Does not apply to GPRS
Posted Jan 10, 2010 14:08 UTC (Sun) by mjr (guest, #6979) [Link]
Here's a random Googled up source for that: http://www.kemt.fei.tuke.sk/predmety/KEMT414_AK/_material...
"GPRS encryption is done with a different family of algorithms: GEA0 (none), GEA1 (export), GEA2 (normal strength) and GEA3 (new, and effectively the same as A5/3). Note that the GEA1 and GEA2 algorithms do not have any relationship to the A5/1 and A5/2 algorithms, and they are not publicly known. There are no problems with any of these in the open literature."
phone communication has never been secure against evesdroppers
Posted Jan 16, 2010 10:33 UTC (Sat) by dlang (guest, #313) [Link]
the means to listen in has evolved, but it's always been the case that access to the phone companies equipment has given access to the contents of phone calls and messages.
As for the scare about how SMS is being used to protect your bank account, the security provided by such mechanisms isn't provided by the message being encrypted (at least not in any sane implementation), it's provided by the fact that it is being sent through a separate channel from the rest of the authentication (making it hard for an attacker to tap both channels), and the fact that it's a single-use code.