Re:The forbidden fruits of radio
on
GNU Radio
·
· Score: 1
With CDMA, you have to discover the seed value for a particular handset, and *then* crack the crypto.
This is not the case. On the forward channel (basestation to handset) only 64 spreading codes are used. Hence it is easy to grab all the bits destined for all the handsets in the cell.
Once you've got the raw bits then you take advantage of a flaw (or feature depending on one's point of view) in the protocol that allows you to solve for the per handset crypto key (42 bits). I turns out that there is bunch of redundancy in the signal transmitted from the base station to the mobile. The other "feature" is that the "encryption" function is linear function.
Worst case it takes one second to gather the data required to set up a system of 42 equations in 42 unknowns. A quick look at the IS-95 spec and an little linear algebra will provide insight. Why it takes 1 second to gather the data is that a couple of bits get randomly hammered in a window of 16 out of every 24 bits for power control, hence only 8 out of 24 bits are useful for setting up the system of equations.
Once you've got the handset key, then, if you care, you can use that key to demodulate the reverse channel (mobile to basestation), but it's often the case that you can hear both sides of the conversation just listening to the forward channel.
Of course, there may still be weaknesses or backdoors in these modern implementations, and more widely-available equipment means they're more likely to be discovered. It's still wrong to claim no real protections have been introduced at all.
Personally, I prefer my crypto without deliberate flaws. I argue that "pretend crypto" is worse than no crypto at all. Let's at least be clear that IS-136 and IS-95 are both fundamentally broken. GSM takes a little more work, but having the low 10 bits of the 64 bit set to zero does make the job easier.
Re:This won't let you listen to cellular.
on
GNU Radio
·
· Score: 1
> and I can tell you this won't help you listen to cellular.
Look, we're sucking down 6+ MHz of IF bandwidth, so that's no issue. Take a look at this screenshot for lots of narrow band signals, or this for spread spectrum.
If one were inclined to listen to cellular, the GNU Radio platform has plenty of umph to decode all the 2nd and 2.5G cellular standards.
Note that when doing most of the work in software, you organize the system differently than using the intersil digital down converters.
To give you a couple of ideas about how we do it, we use a highly decimating FIR filter merged with the software frequency translation for the channel selection. Once you're down to something like 2x or 4x the symbol rate, the cellular standards are no big deal computationally. Yes, there are a lot of layers, but so what? The data rate is really low.
If you download the code, the relevant class for the narrow band channel selection is ~/gnuradio/src/gnu/lib/gr/GrFreqXlatingFIRfilter.h
The content folks at the MPAA Copy Protection Technology Working Group are already sweating. I spoke to them in February about free software, software defined radio, GNU Radio and our ATSC receiver project. The audience was about 1/2 techical and 1/2 lawyers. The lawyerly side from the content producers are the folks bringing you the Hollings bill.
Some of the technical folks from consumer electronics companies were sure that what we are doing was impossible, and even if we could do it, no self respecting engineer would *gasp* give the source away. A few of them were more sanguine and understood fully the implications of what we're building.
Re:I see some potential here.
on
GNU Radio
·
· Score: 1
Absolutely. The whole idea with SDR is flexibility. There's nothing stopping you (technically) from building encrypted transceivers, etc.
As far as I can tell, at least in the US unlicensed bands, you should be able to build a legal direct sequence frequency hopping transceiver that uses a cryptographic spreading code. The FCC regs have particular requirements WRT bandwidth, etc, but there's no reason you can't meet those requirements and still end up with a LPI (low probability of intercept) LPD (low probability of detection) communication system.
The comments above re bandwidth etc are correct. Using the cable modem tuner our bandwidth is effectively limited by the SAW filter in the tuner module. It's sets an IF bandwidth of about 6.5 MHz.
The best SDR type A/D I've come across is the Analog Devices AD6645. It'll do 80 megasamples/sec at 14 bits. It's also capable of bandpass (aka direct IF) sampling.
Re:The forbidden fruits of radio
on
GNU Radio
·
· Score: 1
One of our goals is to disabuse people of the notion that there's much security in any of the current wireless protocols. They are all pretty much flawed.
GNU Radio provides a platform where folks can experiment with the current and emerging digital (and analog) communications standards, and actually see how they are implemented.
There's plenty of work to be done. We've got the infrastructure into a usable (by highly motivated people) state, but there are lots of modulators and demodulators still to be written, as well as support for scripting, better GUIs, etc.
Contrary to what the DSP vendors will tell you, todays PIII, P4 and Athlons kick major butt on the vast majority of DSPs. Clearly for handheld, or other low power applications, the 16 bit fixed point DSPs from TI, or ADI are wonderful, but don't forget that you get to program them in assembler.
On the GNU Radio end, we're out to show that conventional processors (which get faster with no work by any of us software types) are capable, and in fact, actually superior at many signal processing tasks. For instance, a dual processor Athlon 1800+ MP can evaluate 4.8 BILLION FIR filter taps / second. Try to find a DSP that'll do that.
Re:Sounds interesting, there is a similar project
on
GNU Radio
·
· Score: 2, Informative
The DSP-10 is a cool project. Some of the things that distinguish GNU Radio from it is our preference for a *much* wider IF bandwidth, and our use of conventional CPUs instead of DSPs. The vast majority of our code is in C++, versus Analog Devices 21xx DSP assembler.
GNU Radio hardware requirements
on
GNU Radio
·
· Score: 1
Hi, this is Eric Blossom. I'm the primary maintainer on GNU Radio. With regard to hardware requirements, there are several things that will work. It all depends on what you are trying to do.
Those of us who are currently doing most of the work on GNU Radio are using an off the shelf 20 million sample/second A/D card made by Measurement Computing. It's not cheap, about $1300 US, but its the best value we've found so far.
We're using this card in combination with a tuner module designed for cable modems. This allows us to receive pretty much anything from 50 MHz up to 890 MHz and we get to suck down about 6 MHz worth of usable spectrum centered at a particular frequency. This means that depending on what we're looking at, we can either process many narrow band signals simultaneously or a single wide band signal. Examples of narrow band signals include conventional FM broadcast, cellular, paging, etc. The wide band signals that we have currently been spending most of our time on are ATSC (Advanced Television Systems Committee) digital broadcast TV.
Others have talked about using conventional sound cards, AC97 codecs etc along with a narrow band downconverter of some kind. The software supports I/O using sound cards, but somebody, perhaps from the amateur radio community needs to draw up a simple schematic that's straight forward to build.
Slashdot Mirror
With CDMA, you have to discover the seed value for a particular handset, and *then* crack the crypto.
This is not the case. On the forward channel (basestation to handset) only 64 spreading codes are used. Hence it is easy to grab all the bits destined for all the handsets in the cell.
Once you've got the raw bits then you take advantage of a flaw (or feature depending on one's point of view) in the protocol that allows you to solve for the per handset crypto key (42 bits). I turns out that there is bunch of redundancy in the signal transmitted from the base station to the mobile. The other "feature" is that the "encryption" function is linear function.
Worst case it takes one second to gather the data required to set up a system of 42 equations in 42 unknowns. A quick look at the IS-95 spec and an little linear algebra will provide insight. Why it takes 1 second to gather the data is that a couple of bits get randomly hammered in a window of 16 out of every 24 bits for power control, hence only 8 out of 24 bits are useful for setting up the system of equations.
Once you've got the handset key, then, if you care, you can use that key to demodulate the reverse channel (mobile to basestation), but it's often the case that you can hear both sides of the conversation just listening to the forward channel.
Of course, there may still be weaknesses or backdoors in these modern implementations, and more widely-available equipment means they're more likely to be discovered. It's still wrong to claim no real protections have been introduced at all.
Personally, I prefer my crypto without deliberate flaws. I argue that "pretend crypto" is worse than no crypto at all. Let's at least be clear that IS-136 and IS-95 are both fundamentally broken. GSM takes a little more work, but having the low 10 bits of the 64 bit set to zero does make the job easier.
> and I can tell you this won't help you listen to cellular.
h
Look, we're sucking down 6+ MHz of IF bandwidth, so that's no issue. Take a look at this screenshot for lots of narrow band signals, or this for spread spectrum.
If one were inclined to listen to cellular, the GNU Radio platform has plenty of umph to decode all the 2nd and 2.5G cellular standards.
Note that when doing most of the work in software, you organize the system differently than using the intersil digital down converters.
To give you a couple of ideas about how we do it, we use a highly decimating FIR filter merged with the software frequency translation for the channel selection. Once you're down to something like 2x or 4x the symbol rate, the cellular standards are no big deal computationally. Yes, there are a lot of layers, but so what? The data rate is really low.
If you download the code, the relevant class for the narrow band channel selection is ~/gnuradio/src/gnu/lib/gr/GrFreqXlatingFIRfilter.
The content folks at the MPAA Copy Protection Technology Working Group are already sweating. I spoke to them in February about free software, software defined radio, GNU Radio and our ATSC receiver project. The audience was about 1/2 techical and 1/2 lawyers. The lawyerly side from the content producers are the folks bringing you the Hollings bill.
Some of the technical folks from consumer electronics companies were sure that what we are doing was impossible, and even if we could do it, no self respecting engineer would *gasp* give the source away. A few of them were more sanguine and understood fully the implications of what we're building.
Absolutely. The whole idea with SDR is flexibility. There's nothing stopping you (technically) from building encrypted transceivers, etc.
As far as I can tell, at least in the US unlicensed bands, you should be able to build a legal direct sequence frequency hopping transceiver that uses a cryptographic spreading code. The FCC regs have particular requirements WRT bandwidth, etc, but there's no reason you can't meet those requirements and still end up with a LPI (low probability of intercept) LPD (low probability of detection) communication system.
Have at it!
The comments above re bandwidth etc are correct. Using the cable modem tuner our bandwidth is effectively limited by the SAW filter in the tuner module. It's sets an IF bandwidth of about 6.5 MHz.
The best SDR type A/D I've come across is the Analog Devices AD6645. It'll do 80 megasamples/sec at 14 bits. It's also capable of bandpass (aka direct IF) sampling.
One of our goals is to disabuse people of the notion that there's much security in any of the current wireless protocols. They are all pretty much flawed.
GNU Radio provides a platform where folks can experiment with the current and emerging digital (and analog) communications standards, and actually see how they are implemented.
There's plenty of work to be done. We've got the infrastructure into a usable (by highly motivated people) state, but there are lots of modulators and demodulators still to be written, as well as support for scripting, better GUIs, etc.
Contrary to what the DSP vendors will tell you, todays PIII, P4 and Athlons kick major butt on the vast majority of DSPs. Clearly for handheld, or other low power applications, the 16 bit fixed point DSPs from TI, or ADI are wonderful, but don't forget that you get to program them in assembler.
On the GNU Radio end, we're out to show that conventional processors (which get faster with no work by any of us software types) are capable, and in fact, actually superior at many signal processing tasks. For instance, a dual processor Athlon 1800+ MP can evaluate 4.8 BILLION FIR filter taps / second. Try to find a DSP that'll do that.
The DSP-10 is a cool project. Some of the things that distinguish GNU Radio from it is our preference for a *much* wider IF bandwidth, and our use of conventional CPUs instead of DSPs. The vast majority of our code is in C++, versus Analog Devices 21xx DSP assembler.
Hi, this is Eric Blossom. I'm the primary maintainer on GNU Radio. With regard to hardware requirements, there are several things that will work. It all depends on what you are trying to do.
Those of us who are currently doing most of the work on GNU Radio are using an off the shelf 20 million sample/second A/D card made by Measurement Computing. It's not cheap, about $1300 US, but its the best value we've found so far.
We're using this card in combination with a tuner module designed for cable modems. This allows us to receive pretty much anything from 50 MHz up to 890 MHz and we get to suck down about 6 MHz worth of usable spectrum centered at a particular frequency. This means that depending on what we're looking at, we can either process many narrow band signals simultaneously or a single wide band signal. Examples of narrow band signals include conventional FM broadcast, cellular, paging, etc. The wide band signals that we have currently been spending most of our time on are ATSC (Advanced Television Systems Committee) digital broadcast TV.
Others have talked about using conventional sound cards, AC97 codecs etc along with a narrow band downconverter of some kind. The software supports I/O using sound cards, but somebody, perhaps from the amateur radio community needs to draw up a simple schematic that's straight forward to build.