MyCard

From C3L Wiki

Jump to: navigation, search


Contents

General RFID Info

For general information and resources on RFID, see our RFID page. See especially the Henry Plötz and Karsten Nohl's talk from 25C3!

What is MyCard

Citation from uni.lu: "To be admitted to the canteen, students registered at the University will need “myCard,” which they can collect at the SEVE. This card can be recharged either directly at the canteen or on the web at www.restopolis.lu for a sum of €25, €50 or €100."

Well, these cards are used in the whole country, in every school, university and so on.


What is the problem

Well, I didn't manage to get any information related to this card. I sent an e-mail to the accountable person at the university and followed their response to contact the restopolis-people themselves. I never got an answer. (Same thing with the second try) They force people to use a card, to get something to eat. The system is based on centralised server, (I presume) where a lot of things might be logged, for example what I eat at university, or pupils at school. They present us the nice side of the card, the layout and colours are known (see top right corner) but _nothing_ related to security and personal data handling is known.

Possible scenarios

Possible usage scenario of food consumption data

Here I'll present a short scenario what could happen if things go very wrong, which might be possible as nothing is known. Image a young pupil, 10 years old, has to eat in the canteen until he finishes his master at university (aged 25). We'll simply call this pupil K. K doesn't like salad and soup very much, so he prefers to eat the things he likes. So he eats 2 pizzas and 3 times chips a week during 15 years and consumes 2l of limo each day. Well, pupil all over the world do that every day. But here, the situation is another! In fact, due to this card, it might be possible to trace who is using it. For example through the credit card number that is used to upload money on this card. Imagine, a centralised database where is written down what you eat during 15 years. This might be very interesting information for insurance companies for example. This is very frightening! So I think it is very important to get more information about this card. If some persons would like to help me, you're all welcome!
--Kabel 00:29, 24 June 2008 (CEST)

Restopolis has adapted its standard form contract, they claim saving personalized data not for more than a month (although they also claim that they save "anonymized" data for as long as a year). Besides the fact that it is virtually impossible to prove wheter Restopolis keeps to these durations or not, there is also another problematic point: The 1 month food history is only enabled for pupils under the age of 16 by default. A possibility to manually enable the food history for elder students is claimed to be available, however it is impossible to disable the food history again after it has once it is enabled ("L'option de la génération de l'historique personnel une fois activée, le client ne pourra plus la désactiver."). It seems doubtful that this restriction complies with Luxembourgish informationial self-determination and information privacy legislation.

Extract of the link Restopolis standard form contract 

Article 11.- Historique des consommations

Pour les clients mineurs n'ayant pas encore atteint l'âge de 16 ans, l'historique des consommations est stocké de façon nominative et ceci pendant un mois. Cet historique fait fonction d’extrait de compte et permet au client de vérifier à tout moment les opérations de crédit et de débit effectuées sur son compte virtuel ainsi que le solde de ce dernier. L'historique nominatif affiche la catégorie de chaque collation sans en donner le détail, la date de la transaction et le montant débité respectivement crédité. Après la période d'un mois, les données en relation avec le client sont anonymisées et il ne sera par conséquent plus possible d'établir une relation entre consommations et clients.

Le jour même où le client atteint l'âge de 16 ans le stockage nominatif de son historique est arrêté. Le relevé de ses consommations continue à être stocké mais ceci de façon anonyme et à des fins de comptabilité du service Restopolis sans qu'une relation quelconque avec le client ne soit maintenue. Pourtant le client a l'option d'activer le stockage nominatif de l'historique de ses consommations. L'option de la génération de l'historique personnel une fois activée, le client ne pourra plus la désactiver.

Au cas où l'historique nominatif n'est pas activé, seul le ticket de caisse fait preuve en cas de litige avec le responsable de traitement.

D'une manière générale, les données en relation avec les consommations du client sont stockées pendant l’année scolaire en cours.
À chaque rentrée scolaire, l'historique est purgé et par conséquent définitivement effacé.

--Hardfalcon 23:05, 13 January 2009 (UTC)

Password issues

Screenshots included in the [Media:ManuelCardFive.pdf official manual] for the creation of new cards (using CardFive Professional) suggest that people involved in administrative tasks (in clear English: the guys who made and activated your card at your school) might have access to the password your configured for your card. It is highly probable that many students are using their Restopolis passwords also for other internet sites and services, especially because students were not briefed about the risks these pratices bring with them.
Moreover, some screenshots from the manual suggest that the whole infrastructure is entirely based upon closed source software (for example a Microsoft Access Database), making it virtually impossible even to the ministry of education to tell you what this software is really doing with your data.

Possibility to track usage of public transportation means

After the beginning of the school/university year 2009/2010, the pupils/students will be able to use the public transports with this card. A possible conclusion of this amply action of the government and the school ministry is quite simple: Surveillance at any place and time
In other words: Every pupil/student could be tracked at every step, because when she/he will enter a bus or a train, she/he is obligated to pass her/his card along the rfid reader and with this simple action name, date and time will be logged.
--Prometheus 12:43, 19 December 2008 (CEST)

Technical details

Barcode

The barcode which is printed on the card is the user's social security number as a CODE 128 barcode. If you want to check this for your own card, you might use for example Zebra Barcode Reader.

Reader results

Here's some data.. only I don't have the slightest idea what it all means :( I'll try to get in touch with Mr. Laurie though an read through Henrik Plötz's diploma thesis on RFID over the WE. --Kwisatz 13:28, 31 October 2008 (CET)

We seem to be dealing with a Mifare Classic 4K (another name for Mifare Standard 4K) card, at least this is what the output of isotype.py suggests. This is one of the 2 hacked Mifare chips, the other one is the Mifare Standard 1K.
I know this shouldn't be here, but SCNR: Free meals for everyone!!11!!1 :D
--Hardfalcon 02:37, 4 November 2008 (CET)

isotype.py

kwisatz@hyperion ~/Desktop/RFIDIOt-0.1t $ ./isotype.py 
isotype v0.1h (using RFIDIOt v0.1t)
  Reader: PCSC OMNIKEY CardMan 5x21 00 01

     ID: 4C8BC102
       Tag is ISO 14443 A, part 3

    ATR: 3B8F8001804F0CA0000003060300020000000069
         3B  Initial Header
           8  No TA1, TB1, TC1 only TD1 is following
            F  15 bytes historical data follow
             8  No TA2, TB2, TC2 only TD2 is following
              0  T = 0
               0  No TA3, TB3, TC3, TD3 following
                1  T = 1
                 Detected STORAGECARD
     Historical: 804F0CA00000030603000200000000
                 80  Status indicator may be present (COMPACT-TLV object)
                   4F  Application Identifier presence indicator
                     0C  12 bytes follow
                 RID:  A000000306  PC/SC Workgroup
                           PIX:  03000200000000
                            SS:  03  ISO 14443 A, part 3
                            Name:  0002  Mifare Standard 4K
                                 RFU:  00000000
                                 Checksum TCK: 69 (OK)

readmifaresimple.py

kwisatz@hyperion ~/Desktop/RFIDIOt-0.1t $ ./readmifaresimple.py 
readmifaresimple v0.1c (using RFIDIOt v0.1t)
  Reader: PCSC OMNIKEY CardMan 5x21 00 01
  Card ID: 4C8BC102

    Reading from 00 to 64, key FFFFFFFFFFFF

    Block 000:  Login OK. Data: 4C8BC10204980200648E849549501907 L.......d...IP..
    Block 001:  Login OK. Data: 00000000000000000000000000000000 ................
    Block 002:  Login OK. Data: 00000000000000000000000000000000 ................
    Block 003:  Login OK. Data: 000000000000FF078069FFFFFFFFFFFF .........i......
    Block 004:  Login error: 6982 Security status not satisfied
    Block 005:  Login error: 6982 Security status not satisfied
    Block 006:  Login error: 6982 Security status not satisfied
    Block 007:  Login error: 6982 Security status not satisfied
    Block 008:  Login error: 6982 Security status not satisfied

readmifare1k.py

kwisatz@hyperion ~/Desktop/RFIDIOt-0.1t $ ./readmifare1k.py     
readmifare1k v0.1h (using RFIDIOt v0.1t)
  Reader: PCSC OMNIKEY CardMan 5x21 00 01
Card ID: 4C8BC102

MIFARE data (keytype FF):
	Serial number:		4C8BC102
	Check byte:		04
	Manufacturer data:	980200648E849549501907

 sector 00: Keytype: AA Login Error: 6982 Security status not satisfied
 sector 00: Keytype: BB Login Error: 6982 Security status not satisfied
 sector 00: Keytype: FF Login OK. Data:

  4C8BC10204980200648E849549501907 00000000000000000000000000000000 00000000000000000000000000000000 000000000000FF078069FFFFFFFFFFFF
  Access Block User Data Byte: 69

	Key A (non-readable):	000000000000
	Key B:			FFFFFFFFFFFF
	Access conditions:	FF0780
		MIFAREC1:	0
		MIFAREC2:	0
		MIFAREC3:	8
		MIFAREblock0AC: 000
			Read: KEYA/B, Write: KEYA/B, Increment: KEYA/B, Decrement/Transfer/Restore: KEYA/B (transport configuration)
		MIFAREblock1AC: 000
			Read: KEYA/B, Write: KEYA/B, Increment: KEYA/B, Decrement/Transfer/Restore: KEYA/B (transport configuration)
		MIFAREblock2AC: 000
			Read: KEYA/B, Write: KEYA/B, Increment: KEYA/B, Decrement/Transfer/Restore: KEYA/B (transport configuration)
		MIFAREblock3AC: 001
			Write KeyA: KEYA, Read Access bits: KEYA, Write Access bits: KEYA, Read KeyB: KEYA, Write KeyB: KEYA (KEYB readable, transport configuration)

 sector 01: Keytype: AA Login Error: 6982 Security status not satisfied
 sector 01: Keytype: BB Login Error: 6982 Security status not satisfied
 sector 01: Keytype: FF Login OK. Data:

  Read error: 6982 Security status not satisfied

bruteforce.py

kwisatz@hyperion ~/Desktop/RFIDIOt-0.1t $ ./bruteforce.py 
bruteforce v0.1f (using RFIDIOt v0.1t)
  Reader: PCSC OMNIKEY CardMan 5x21 00 01
Card ID: 4C8BC102
 Tries: 30
error!
key: AA 77714567d583
error code: 6988

loginall.py

kwisatz@hyperion ~/Desktop/RFIDIOt-0.1t $ ./loginall.py 
loginall v0.1f (using RFIDIOt v0.1t)
  Reader: PCSC OMNIKEY CardMan 5x21 00 01

card id: 4C8BC102
00 AA:  error: 6982
00 BB:  error: 6982
00 FF:  success!
01 AA:  error: 6982
01 BB:  error: 6982
01 FF:  success!
02 AA:  error: 6982
02 BB:  error: 6982
02 FF:  success!
03 AA:  error: 6982
03 BB:  error: 6982
03 FF:  success!
04 AA:  error: 6982
04 BB:  error: 6982
04 FF:  error: 6982
05 AA:  error: 6982
05 BB:  error: 6982
05 FF:  error: 6982
06 AA:  error: 6982
06 BB:  error: 6982
06 FF:  error: 6982
07 AA:  error: 6982
07 BB:  error: 6982
07 FF:  error: 6982
08 AA:  error: 6982
08 BB:  error: 6982
08 FF:  error: 6982
09 AA:  error: 6982
09 BB:  error: 6982
09 FF:  error: 6982
0a AA:  error: 6982
0a BB:  error: 6982
0a FF:  error: 6982
0b AA:  error: 6982
0b BB:  error: 6982
readtag v0.1b (using RFIDIOt v0.1t)
  Reader: PCSC OMNIKEY CardMan 5x21 00 01

ID: 4C8BC102
  Data:
    Block 00: read error: 6400
    Block 01: read error: 6400
    Block 02: read error: 6400
    Block 03: read error: 6400
    Block 04: read error: 6982
    Block 05: read error: 6982
    Block 06: read error: 6982
    [...]
    Block db: read error: 6982
    Block dc: read error: 6982


Usernames on Restopolis

General format:

First 3 Letters from the LastName followed by the first 2 letters from the FirstName followed by your national id number. i.e. This fictive person

Frederick Mayerson
19890423274

would have this username: mayfr274

Règlement grand-ducal du 7 juin 1979 fixant les modalités d´application de la loi du 30 mars 1979 organisant l´identification numérique des personnes physiques et morales. 

Art. 1er .
Le numéro d´identité est représenté par un nombre à 11 chiffres qui comprend dans l´ordre
des composantes suivantes:
1) Pour les personnes physiques:
a) l´année de naissance exprimée par 4 chiffres;
b) le mois de naissance exprimé par 2 chiffres (01 à 12);
c) le jour de naissance exprimé par 2 chiffres (01 à 31);
d) un numéro d´ordre à deux chiffres, distinguant les personnes nées le même jour du même mois
de la même année et le sexe de la personne identifiée;
le numéro d´ordre est impair pour les personnes du sexe masculin et pair pour les personnes du
sexe féminin;
e) un indicatif autovérificateur à une position numérique.
La composante a) doit obligatoirement indiquer l´année de naissance, même si cette donnée n´est
que présumée. Les composantes b) et/ou c) sont égales à zéro pour les personnes dont le mois et/ou
le jour de naissance ne sont pas connus.

The check digit named in section e) can be calculated by multiplying the first digit of the social security number by 7, the second digit by 3, the third digit by 1, the fourth digit again by 7, and so on. The units of the obtained products are summed up, the unit of the obtained sum is the check digit.

Screenshot

Data saved on the server

Prepaid cards

A prepaid card contains the following data:

  • Recharge code
    • Covered with a latex layer to be scratched off
    • Used to charge your card via the Restopolis website or with an SMS
  • Serial number
    • Format (just a guess as I have only got a single 25€ card so far): [YYYY] [MM] [amount of money as a 3 digit number] [8 digit serial number]
    • Example: 20070802500072245
  • Serial number as a CODE128 barcode
    • Cashiers read this barcode with their barcode scanner to recharge accounts, they do not have to use the recharge code under the scratch-off layer. Knowing the whole system is based upon a cetralized database, it is as a conclusion probable that the recharge code can be calculated/derived from the serial number, and that the necessary function is implemented in the software client installed at the cashpoints.

--Hardfalcon 13:51, 6 November 2008 (CET)

Invoice numbers

The invoice number of any transaction done at the cash point is printed onto the receipt the student gets. An invoice number is unique troughout the whole country, because the transactions are done via a centralized national server run by the CTE or Restopolis. If you pay 2 separate menus (invoices) just one after each other during "rush hour", you will most probably not get 2 sequent invoice numbers.

Law

New Restopolis "Conditions Générales"

In response to the boycott in the LGE (see #Coverage by the media and public reactions) they changed article 11: 

Article 11.- Historique des consommations

Pour les clients mineurs n'ayant pas encore atteint l'âge de 16 ans, l'historique des consommations est stocké de façon
nominative et ceci pendant un mois. Cet historique fait fonction d’extrait de compte et permet au client de vérifier à
tout moment les opérations de crédit et de débit effectuées sur son compte virtuel ainsi que le solde de ce dernier.
L'historique nominatif affiche la catégorie de chaque collation sans en donner le détail, la date de la transaction et
le montant débité respectivement crédité. Après la période d'un mois, les données en relation avec le client sont
anonymisées et il ne sera par conséquent plus possible d'établir une relation entre consommations et clients.

Le jour même où le client atteint l'âge de 16 ans le stockage nominatif de son historique est arrêté. Le relevé de ses
consommations continue à être stocké mais ceci de façon anonyme et à des fins de comptabilité du service Restopolis sans
qu'une relation quelconque avec le client ne soit maintenue. Pourtant le client a l'option d'activer le stockage nominatif
de l'historique de ses consommations. L'option de la génération de l'historique personnel une fois activée, le client ne
pourra plus la désactiver.

Au cas où l'historique nominatif n'est pas activé, seul le ticket de caisse fait preuve en cas de litige avec le responsable
de traitement.

D'une manière générale, les données en relation avec les consommations du client sont stockées pendant l’année scolaire en
cours.
À chaque rentrée scolaire, l'historique est purgé et par conséquent définitivement effacé.

Art. 1er. Sont autorisés à utiliser le numéro d´identité des personnes physiques et morales les
fichiers suivants:
- les fichiers du personnel enseignant et des élèves du Ministère de l´Education Nationale,
[...]

Chapitre VI. Droits de la personne concernée
Art. 26. Le droit à l’information de la personne concernée
(1) Lorsque des données sont collectées directement auprès de la personne concernée, le responsable du
traitement doit fournir à la personne concernée, au plus tard lors de la collecte et quels que soient les moyens et
supports employés, les informations suivantes, sauf si la personne concernée en a déjà été informée:
(a) l’identité du responsable du traitement et, le cas échéant, de son représentant;
(b) la ou les finalités déterminées du traitement auquel les données sont destinées;
(c) toute autre information supplémentaire telle que:
– les destinataires ou les catégories de destinataires auxquels les données sont susceptibles d’être
communiquées;
– le fait de savoir si la réponse aux questions est obligatoire ou facultative ainsi que les conséquences
éventuelles d’un défaut de réponse;
– l’existence d’un droit d’accès aux données la concernant et de rectification de ces données;
– la durée de conservation des données.
1845
(2) Lorsque les données n’ont pas été collectées auprès de la personne concernée, le responsable du traitement
doit, dès l’enregistrement des données ou, si une communication de données à un tiers est envisagée, au plus tard lors
de la première communication de données, fournir à la personne concernée, sauf si elle en est déjà informée, les
informations suivantes:
(a) l’identité du responsable du traitement et, le cas échéant, de son représentant;
(b) la ou les finalités déterminées du traitement auquel les données sont destinées;
(c) toute information supplémentaire telle que:
– les catégories de données concernées;
– les destinataires ou les catégories de destinataires des données auxquels les données sont susceptibles d’être
communiquées;
– l’existence d’un droit d’accès aux données la concernant et de rectification de ces données;
– la durée de conservation des données.
(3) Quiconque contrevient aux dispositions du présent article est puni d’un emprisonnement de huit jours à un an
et d’une amende de 251 à 125.000 euros ou d’une de ces peines seulement. La juridiction saisie peut prononcer la
cessation du traitement contraire aux dispositions du présent article sous peine d'astreinte dont le maximum est fixé
par ladite juridiction.

Art. 28. Droit d’accès
(1) Sur demande à introduire auprès du responsable du traitement, la personne concernée ou ses ayants droit
justifiant d'un intérêt légitime peuvent obtenir sans frais, à des intervalles raisonnables et sans délais excessifs:
(a) l’accès aux données la concernant;
(b) la confirmation que des données la concernant sont ou ne sont pas traitées, ainsi que des informations portant
au moins sur les finalités du traitement, sur les catégories de données sur lesquelles il porte et les destinataires
ou les catégories de destinataires auxquels les données sont communiquées;
(c) la communication, sous une forme intelligible, des données faisant l’objet des traitements, ainsi que de toute
information disponible sur l’origine des données;
(d) la connaissance de la logique qui sous-tend tout traitement automatisé des données la concernant, au moins dans
le cas des décisions automatisées visées à l’article 31.
(2) Celui qui entrave sciemment par quelque moyen que ce soit, l’exercice du droit d’accès, sera puni d’un
emprisonnement de huit jours à un an et d’une amende de 251 à 125.000 euros ou d’une de ces peines seulement.
[...]

f) Pupil’s cards (p.16)
For the control of access and the monitoring of purchases: Many schools are utilising
pupils' cards not only to control access to the school, but also to monitor the purchases
made by the children. It is questionable if the second purpose is completely compatible
with the privacy of the child, especially after a certain age.
In any case, the two functions should be separated, as the second may raise privacy
issues.
For the location of pupils11: Another means of control used in certain schools (whether
with a card or not) is the location of pupils through RFID badges. In this case, the
relevance of such a system must be justified with regards to the specific risks at stake,
particularly where alternative methods for control are available.

Documentation

Manuals

Coverage by the media and public reactions

"# Datenschutz: Di ganz Daten waat een mettes esst an der Kantin gin mat den Données Personnels vum jeweilegen
Schüler iergendwou zentral gespaichert. Mee wou? Waat geschitt domadden? Ween huet do zougreff drop? Waat gett
domadden gemeet? Mir sin der Meenung dass dee System einfach net transparent genuch ass waat mat den Donnéen vum
Schüler geschitt."
 
free translation (by Kwisatz)

"# Data Protection: All our personal data together with what we eat in our caffeteria, is saved at a central
location. But where? What is that data saved for and who does have access to it? It is our believe that this
technology and the use of our personal data is far from transparent."


Retrieved from "http://www.c3l.lu/wiki/index.php/MyCard"
Personal tools