AW: Plans for GSM / OpenBSC field test at 27C3
Andreas: Do you have some SuperSIM to test the new pySIM patch mode and integrate it with OpenBSC? If not, I will send you some sample cards monday next week. please send me some cards. i have not followed the pySIM talk in the mailing list. what reader do i need?
Re: Plans for GSM / OpenBSC field test at 27C3
Thanks a lot ! On Thu, Dec 09, 2010 at 01:50:02PM +0100, Sylvain Munaut wrote: I merged your pcsc code first, then : - Split into several files (for clarity and also so that if you don't use the pcsc code, it doesn't try to import pysmartcard and the other way around) - Added option to save parameters to CSV file, or directly to an openBSC HLR. (the extension is just 9 + 5 last digits of ICCID, change in the code if required) - Added option to switch to batch mode (including saving state). Takes about a second per card with a pcsc reader. this makes a lot of sense, thanks a lot. As for the actual 27C3 deployment: I can offer at least two PC/SC readers (Omnikey 3121 / 5121) for the GSM helpdesk that Andreas Eversberg will be running. Andreas: Do you have some SuperSIM to test the new pySIM patch mode and integrate it with OpenBSC? If not, I will send you some sample cards monday next week. Regards, Harald -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6)
Re: Plans for GSM / OpenBSC field test at 27C3
Hi Harald, We can give you 55 SIM cards with known Ki. Regards Roch. On 10/26/2010 06:36 PM, Harald Welte wrote: Hi all! As some of you know, we will again have an OpenBSC field test at the Chaos Communication Congress from December 27-30 in Berlin / Germany. I have already applied for the license from the regulatory authority. No feedback yet, but I expect no problems, as it is more or less what we had last year. The only difference is that I've asked for 6 ARFCN (5 last year). It will again be a nanoBTS / GSM 1800 setup. Regarding the overall setup, I want to deviate from what we had last year in the following way: 1) Issue our own SIM cards to permit Authentication + Encryption. This is the perfect way how we can have a A5/1 based network that people can use to play with airprobe + Kraken - without violating any laws. In practise, this will mean we use 16in1 SIM cards, I have already bought 1000 of them. It also means that the GSM helpdesk will have to issue those SIMC cards. I would suggest we simply sell them (as opposed to providing them for a deposit, as we then would have to take back a lot of cards and return money, which is a lot of overhead). We will keep a database of all the IMSI + Ki tuples that we have issued, which we will use as HLR + AuC. This database will be persistent, i.e. at other events like the CCC camp 2011 or 28C3 we expect those SIM cards to be used again without any registration. 2) Provide GPRS + EDGE services using OsmoSGSN and OpenGGSN. I am not sure how stable this will run - but we have a good chacne of catching bugs in our code by running at the event. We will be able to provide real-world IP addresses to every mobile phone, without filter and without NAT ! I am not yet sure how we will deal with dividing the timeslots between GSM and GPRS. The dynamic TCH / PDCH code in OpenBSC hasn't ever been tested, so we might use a static configuration - potentially changing that static config depending on the usage pattern / load we see. 3) Make dual-TRX setups standard (3 BTS with 2TRX each) This is simply to enhance the capacity, particularly of SDCCH/8 resources 4) Consider putting all BTS in the same location area This will significantly reduce our need for signalling channels, but at the expense we no longer know where a particular phone is located in the building. Thus, we might make this optional and see if it is needed for load reasons. 5) Improve the SMS situation The current SMS code still sucks really bad. We don't want this inside OpenBSC, and we still don't do timer-based / automatic delivery. Using the manual 'sms send pending' command causes severe blockage if the queue is getting too large. I will try to squeeze in some time to rewrite this code and make it run as external process. 6) User registration So we sell SIM cards with a pre-programmed IMSI + Ki, but how do we enable users to assign a phone number to them? Ideally I would want them to simply register a phone number at the eventphone.de GURU web interface ahead of the event. But how do we match the IMSI and the phone number? Ask users to simply state the phone number they registered? How do we get some kind of authentication? Comments and additions are most welcome, Harald -- Roch-Alexandre Nominé CTO On-Waves ehf Armuli 25, IS-108, Reykjavik, Iceland Tel: +33 666 299 012
Re: Plans for GSM / OpenBSC field test at 27C3
Hi Roch, On Thu, Oct 28, 2010 at 12:57:13PM +, Roch wrote: We can give you 55 SIM cards with known Ki. Thanks a lot for the offer, but there is no need. As indicated, I have already bought 1000 sim cards with freely programmable Ki (and COMP128v1 as A3/A8), and we will sell those at the 27C3 for a small amount of money... The 'problem' with those cards is that anyone can read and write the Ki, so they are not something that any operator would ever use. But it's exactly the rihgt thing for RD and testing use... -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6)
AW: Plans for GSM / OpenBSC field test at 27C3
Each SIM has a 'default' number, and if they want to instead use a number they pre-registred, have them text a 'token' (long enough not to guess a valid one, but not too long as to be annoying). That token is just displayed on eventphone.de when they register a number as 'GSM' without an IMSI. ok, the other way around. The token is a unique value that they have to SMS to OpenBSC... great idea. I like it that way. i would like to ask eventphone to add a 10 digits token to the registration tool. this way it is hard enough guess. the token shall be generated randomly when not yet assigned to a phone number. the token is used to authenticate: - by sending SMS with the token (like said above) - by dialing a service number and entering the token - by giving the token to the GSM help desk.
Re: Plans for GSM / OpenBSC field test at 27C3
Hi! On Tue, 2010-10-26 at 19:36 +0100, Harald Welte wrote: We will keep a database of all the IMSI + Ki tuples that we have issued, which we will use as HLR + AuC. This database will be persistent, i.e. at other events like the CCC camp 2011 or 28C3 we expect those SIM cards to be used again without any registration. Which MCC/MNC would be used for the IMSI? We will probably need to use different ones for other events (at least for those not in germany). Also do you already have a schedule for the network setup? Best regards, Jan
Plans for GSM / OpenBSC field test at 27C3
Hi all! As some of you know, we will again have an OpenBSC field test at the Chaos Communication Congress from December 27-30 in Berlin / Germany. I have already applied for the license from the regulatory authority. No feedback yet, but I expect no problems, as it is more or less what we had last year. The only difference is that I've asked for 6 ARFCN (5 last year). It will again be a nanoBTS / GSM 1800 setup. Regarding the overall setup, I want to deviate from what we had last year in the following way: 1) Issue our own SIM cards to permit Authentication + Encryption. This is the perfect way how we can have a A5/1 based network that people can use to play with airprobe + Kraken - without violating any laws. In practise, this will mean we use 16in1 SIM cards, I have already bought 1000 of them. It also means that the GSM helpdesk will have to issue those SIMC cards. I would suggest we simply sell them (as opposed to providing them for a deposit, as we then would have to take back a lot of cards and return money, which is a lot of overhead). We will keep a database of all the IMSI + Ki tuples that we have issued, which we will use as HLR + AuC. This database will be persistent, i.e. at other events like the CCC camp 2011 or 28C3 we expect those SIM cards to be used again without any registration. 2) Provide GPRS + EDGE services using OsmoSGSN and OpenGGSN. I am not sure how stable this will run - but we have a good chacne of catching bugs in our code by running at the event. We will be able to provide real-world IP addresses to every mobile phone, without filter and without NAT ! I am not yet sure how we will deal with dividing the timeslots between GSM and GPRS. The dynamic TCH / PDCH code in OpenBSC hasn't ever been tested, so we might use a static configuration - potentially changing that static config depending on the usage pattern / load we see. 3) Make dual-TRX setups standard (3 BTS with 2TRX each) This is simply to enhance the capacity, particularly of SDCCH/8 resources 4) Consider putting all BTS in the same location area This will significantly reduce our need for signalling channels, but at the expense we no longer know where a particular phone is located in the building. Thus, we might make this optional and see if it is needed for load reasons. 5) Improve the SMS situation The current SMS code still sucks really bad. We don't want this inside OpenBSC, and we still don't do timer-based / automatic delivery. Using the manual 'sms send pending' command causes severe blockage if the queue is getting too large. I will try to squeeze in some time to rewrite this code and make it run as external process. 6) User registration So we sell SIM cards with a pre-programmed IMSI + Ki, but how do we enable users to assign a phone number to them? Ideally I would want them to simply register a phone number at the eventphone.de GURU web interface ahead of the event. But how do we match the IMSI and the phone number? Ask users to simply state the phone number they registered? How do we get some kind of authentication? Comments and additions are most welcome, Harald -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Plans for GSM / OpenBSC field test at 27C3
Hi, 1) Issue our own SIM cards to permit Authentication + Encryption. This is the perfect way how we can have a A5/1 based network that people can use to play with airprobe + Kraken - without violating any laws. I was planning to enhance pySim to allow more batch programming and support for pc/sc reader (so you just have to insert, wait, remove, insert, wait, ...). I will probably do that soon, after DeepSec. I would suggest we simply sell them (as opposed to providing them for a deposit, as we then would have to take back a lot of cards and return money, which is a lot of overhead). Definitely. I don't see any people having a problem with paying a few EUR for a SIM. Should : - Personal SIM with IMSI/KI/algo specified - Personal/official SIM with just known IMSI be allowed as well ? 4) Consider putting all BTS in the same location area I didn't see the logs / analysis from last year, but : - Was the 'location' feature really exploited for something ? - Was paging a limit ? (if all are in the same area, the number of paging request would triple I guess). - What was the usage of sdcch/8 / TCH ? Would TCH/H with AMR be useful ? (i.e. was tch a limit ?) 6) User registration So we sell SIM cards with a pre-programmed IMSI + Ki, but how do we enable users to assign a phone number to them? Ideally I would want them to simply register a phone number at the eventphone.de GURU web interface ahead of the event. But how do we match the IMSI and the phone number? Ask users to simply state the phone number they registered? How do we get some kind of authentication? Well, I guess SMS is the easier. What kind of control can you have on the eventphone.de interface ? Each SIM has a 'default' number, and if they want to instead use a number they pre-registred, have them text a 'token' (long enough not to guess a valid one, but not too long as to be annoying). That token is just displayed on eventphone.de when they register a number as 'GSM' without an IMSI. Other option is IMEI. They put the IMEI on evenphone.de and when we get a registration we know who to link. Cheers, Sylvain
Re: Plans for GSM / OpenBSC field test at 27C3
Hi Sylvain, On Tue, Oct 26, 2010 at 08:59:27PM +0200, Sylvain Munaut wrote: 1) Issue our own SIM cards to permit Authentication + Encryption. This is the perfect way how we can have a A5/1 based network that people can use to play with airprobe + Kraken - without violating any laws. I was planning to enhance pySim to allow more batch programming and support for pc/sc reader (so you just have to insert, wait, remove, insert, wait, ...). I will probably do that soon, after DeepSec. ok, great. looking forward to it. Should : - Personal SIM with IMSI/KI/algo specified I think the number of people who have that is very limited. So sure, we can do that manually if somebody wants to. - Personal/official SIM with just known IMSI be allowed as well ? I don't think we should do it, or at least not publicly advertise it. It just creates extra effort, and we want to ensure we can enable many people to test the network without creating a lot of per-user work for us. 4) Consider putting all BTS in the same location area I didn't see the logs / analysis from last year, but : - Was the 'location' feature really exploited for something ? no, it's just nice to see and for debugging. And you can see - Was paging a limit ? (if all are in the same area, the number of paging request would triple I guess). No, paging is never a limit... there are so many paging slots and so few calls or SMSs - What was the usage of sdcch/8 / TCH ? I don't really have statistics for it, but TCH use was relatively low... I think people are more interested in reliable SMS. Would TCH/H with AMR be useful ? (i.e. was tch a limit ?) No, TCH was no limit. AMR/HR would be useful, but I don't want to use it as we only have it in OsmoBSC mode so far and no code for codec negotiation in our call control engine. Also, AMR/HR is incompatible with dynamic PDCH allocation, which sucks. 6) User registration So we sell SIM cards with a pre-programmed IMSI + Ki, but how do we enable users to assign a phone number to them? Ideally I would want them to simply register a phone number at the eventphone.de GURU web interface ahead of the event. But how do we match the IMSI and the phone number? Ask users to simply state the phone number they registered? How do we get some kind of authentication? Well, I guess SMS is the easier. Ah, indeed. So we simply allow all IMSIs that we have issued on our network but send them a SMS with some token that they can use to associate that IMSI with their account on GURU? What kind of control can you have on the eventphone.de interface ? We have to discuss it with them... I think now we still might have time for that. Each SIM has a 'default' number, and if they want to instead use a number they pre-registred, have them text a 'token' (long enough not to guess a valid one, but not too long as to be annoying). That token is just displayed on eventphone.de when they register a number as 'GSM' without an IMSI. ok, the other way around. The token is a unique value that they have to SMS to OpenBSC... great idea. I like it that way. Other option is IMEI. They put the IMEI on evenphone.de and when we get a registration we know who to link. too cumbersome for most users from my experience. -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Plans for GSM / OpenBSC field test at 27C3
On 10/26/2010 08:36 PM, Harald Welte wrote: 5) Improve the SMS situation The current SMS code still sucks really bad. We don't want this inside OpenBSC, and we still don't do timer-based / automatic delivery. Using the manual 'sms send pending' command causes severe blockage if the queue is getting too large. I will try to squeeze in some time to rewrite this code and make it run as external process. Okay, we should also have notifications so that we can deliver SMS during a LU or other events where we happen to have a channel available. I am not sure that this is available in any of the speced protocols. One far fetched goal would be to complete the osmo-bsc before the 27C3 and then move the bsc_hack code behind the A-link on top of the improved SMS situation.
