This application claims priority to European Patent Application No. 13 164 396.7, filed on Apr. 19, 2013, the entirety of which is incorporated by reference herein.
1. Technical Field
The present subject matter relates to methods for charging and redeeming electronic tickets in a traffic telematics system.
2. Background Art
Traffic telematics systems are used for a large number of different applications, whether for electronic identification of a vehicle or for payment of road, access, area or city charges, for payment of parking fees, for access control (for example barrier systems), for electronic vehicle registration (EVR), etc. For this purpose, onboard units (OBUs) are often equipped with a short-range communication module in accordance with the DSRC (dedicated short range communication) standard so that they can be localised to the local radio coverage range of an interrogating radio beacon.
Here, electronic tickets can be charged in onboard units and then used for redemption at a wide range of types of radio beacon, for example in order to pay at a radio beacon a road toll fee (“toll fee ticket”), in order to pay a parking fee (“parking ticket”), in order to pay an entrance fee (“entrance ticket”), or in order to settle payment of goods or services, for example for a weather service, data service, information or entertainment service, or the like.
In order to ensure the integrity of such an electronic ticket over the transmission path between, for example, a ticket-issuing central system, a ticket-transporting onboard unit and a ticket-redeeming radio beacon, symmetrical key pairs are currently used in known traffic telematics systems and have to be exchanged by the communication partners before the communication. This requires a secured key distribution method, with correspondingly high outlay in terms of time, organisation and cost.
Document WO 2009/082748 A1 describes a payment system in a vehicle wherein an onboard unit communicates with a merchant via a transceiver. To conduct a transaction, a reader of the onboard unit recognizes, e.g., a mobile phone which accesses an online account via an internet connection, whereupon the transaction is processed via the online account and/or the onboard unit sends payment information (e.g., credit card number) to the merchant. The radio communication between the onboard unit and the merchant can be secured, e.g., by means of an encryption system using private and public keys.
Document WO 02/042225 A2 shows an encryption of tickets by means of public and private keys: The tickets are encrypted by a central station with a public key of, e.g., a mobile phone, whereupon the encrypted ticket is sent to the mobile phone. The mobile phone can then decrypt the ticket with its private key and redeem it at a redeeming system.
An object of the disclosed subject matter is to overcome the disadvantages of the presented art and to create an improved ticket-issuing and ticket-redeeming method for electronic tickets in a traffic telematics system.
This object is achieved in a first aspect with a method for charging an onboard unit with an electronic ticket and redeeming said ticket or a ticket derived therefrom at a radio beacon of a traffic telematics system, wherein the onboard unit has a DSRC interface for radio communication with the radio beacon and a second interface for radio communication with a mobile phone, said second interface being separate from the DSRC interface, comprising:
providing the onboard unit with a public and a private electronic key of the onboard unit;
in the mobile telephone, receiving the public onboard unit key from the onboard unit,
transmitting a ticket request with the public onboard unit key to a central system via the mobile network,
receiving a ticket encrypted with the public onboard unit key via the mobile radio network from the central system,
sending the ticket encrypted with the public onboard unit key from the mobile phone to the onboard unit;
in the onboard unit, receiving via the second interface of the onboard unit the ticket encrypted with the public onboard unit key,
decrypting the received ticket using the private onboard unit key, and
transmitting the ticket or a ticket derived therefrom via the DSRC interface to the radio beacon for redemption.
In the present description, DSRC and a DSRC interface are understood to mean a short-range communication via a radio range of at most a few metres, a few tens of metres or a few hundred metres, as is implemented for example by the DSRC (dedicated short range communication), CEN-DSRC, UNI-DSRC, IEEE 802.11p or WAVE (wireless access for vehicular environments) or ITS-G5 standards, including WLAN and Wifi®, Bluetooth® or also active and passive RFID (radio frequency identification) technologies.
An embodiment relates to the use of asymmetric encryption methods (“public/private key encryption”) and a separate interface, suitable for this encryption, of the onboard unit, via which interface the ticket can be brought into (charged) in the onboard unit. The asymmetric encryption eradicates the need for a secured key distribution method, as is necessary in the case of symmetric keys. Any onboard unit can thus be provided with its own key pair formed of public and private onboard unit keys, for example during the manufacturing process, without the need for the other communication partners, for example the ticket issuer, to know the private onboard unit keys during operation.
The use of a mobile telephone, in particular of an NFC-enabled mobile telephone and an NFC interface between mobile telephone and DSRC onboard unit, facilitates the handling process here and the secured, encrypted ticket transfer from the central system to the onboard unit with the aid of a mobile network (public land mobile network, PLMN) on the one hand and a wireless or NFC radio interface on the other hand.
In an embodiment, the second interface may be a wireless interface, such as an NFC interface, which substantially simplifies the handling of the charging of an onboard unit with an electronic ticket. NFC (near field communication) is a radio communication technology via extremely short radio ranges of at most a few centimetres or a few tens of centimetres and therefore requires close proximity of the onboard unit in order to establish the communication and to bring the ticket into the onboard unit, which gives the user assurance of addressing precisely this onboard unit.
An example embodiment is characterised in that the radio beacon is provided with a public and a private electronic key of the radio beacon or of a central system of the traffic telematics system, and in that the decrypted ticket or the ticket derived therefrom before the transmission to the radio beacon is re-encrypted in the onboard unit using the public radio beacon or public central system key. The ticket or derived ticket may then, for example, be decrypted in the radio beacon using the private radio beacon key or private central system key.
This embodiment is based on a trusted onboard unit, in which a key change is implemented from a first encryption between ticket-issuing central system and ticket-transporting onboard unit on the one hand to a second encryption between ticket-transporting onboard unit and ticket-redeeming radio beacon on the other hand. Ticket issuers (for example central systems) and ticket redeemers (radio beacons) therefore require no knowledge from one another concerning private keys, thus facilitating the handling and key distribution significantly.
In a further aspect the method also comprises the issuing of the ticket in a central system of the traffic telematics system provided with a public and a private electronic key, specifically comprising the following steps:
issuing the ticket;
signing the ticket using the private central system key;
encrypting the ticket using the public onboard unit key; and
transmitting the encrypted ticket to the onboard unit via the second interface thereof.
In the onboard unit, the ticket may, for example, be validated with the aid of the public central system key and only then, if it is valid, is the ticket or the ticket derived therefrom transmitted to the radio beacon for redemption. Therefore, not only can the change of the encryption be performed in the trusted environment of the onboard unit, but also an additional security check of the validity of the ticket, if desired.
Alternatively or additionally, the ticket or the ticket derived therefrom can also be validated in the radio beacon with the aid of the public central system key and only then redeemed if valid.
The public radio beacon key or public central system key (depending on which of these keys is necessary) can be stored in the onboard unit, for example during the manufacturing process. Alternatively, this may also occur “on the fly”, that is to say the public radio beacon key or central system key may, for example, be transmitted from the radio beacon via the DSRC interface to the onboard unit.
The public central system key may also be transmitted together with the ticket or the derived ticket, however.
In accordance with a further example feature, the ticket is provided with a unique identification in the central system, and it is checked in the onboard unit whether the identification of a received ticket is contained in a list of stored identifications, and only then, if it is not contained, is the ticket or the ticket derived therefrom transmitted to the radio beacon for redemption.
It is thus ensured that no malversations can occur during the charging process: an electronic ticket issued by the central system and brought into the onboard unit has a unique identification, which is “used up” in the event of a charging process, since it is now stored in the list of the onboard unit and is no longer valid in the event of a subsequent charging process.
The electronic ticket can be stored in the onboard unit, that is to say transported thereby and then later redeemed in this form at the radio beacon. Alternatively, the ticket in the onboard unit can be introduced into an electronic purse of the onboard unit and the derived ticket can then optionally be derived from the electronic purse. The derived ticket for example has a fraction or a multiple of the monetary value of the original electronic ticket: a plurality of “smaller” derived tickets for redemption at radio beacons can be generated from an electronic ticket stored in the onboard unit via the electronic purse, or a plurality of electronic tickets loaded into the electronic purse can together form a “larger” derived ticket. The electronic purse with the electronic ticket(s) contained therein thus constitutes a “deposit”, from which it is possible to “pay” via the DSRC interface at radio beacons with the aid of the tickets derived therefrom.
The aforementioned unique identification of the ticket may be a transaction identification or, in the simplest case, also merely a timestamp.
Further features and advantages, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings.
The present subject matter will be explained in greater detail hereinafter on the basis of exemplary embodiments illustrated in the accompanying drawings, in which:
Embodiments will now be described with reference to the accompanying drawings.
The electronic ticket 3 is a file which represents an actual value, for example authorised for the purchase of a service, such as the entrance to an area or building (“entrance ticket”), for use of a parking space (“parking ticket”), the use of a section of road or an area (“toll fee ticket”), or generally the purchase of goods or services (“electronic money”).
The radio beacon 4 is an electronic system, at which the electronic ticket 3 can be redeemed in order to authorise entry, parking, road use or goods or services. For example, the radio beacon 4 is arranged at a road (road side entity, RSE) in order to charge for the use of a section of said road by redeeming an electronic ticket 3. Alternatively, the radio beacon 4 is a parking meter, at which an electronic ticket 3 is redeemed in order to pay for a parking space. The radio beacon 4, as is illustrated symbolically at 5, alternatively may be part of a barrier system, which releases an entrance barrier upon redemption of an electronic ticket 3, etc., etc.
The radio beacon 4 is formed in accordance with the DSRC (dedicated short range communication) standard and is designed to establish DSRC radio communication with DSRC onboard units (OBUs) 7 via a DSRC radio interface 6. Such an OBU 7 is carried for example by a vehicle (not illustrated), for example is attached to the inner side of the windscreen, but may also be carried by the user where appropriate.
In the present description, DSRC and a DSRC interface are understood to mean a short-range communication via a radio range of at most a few metres, a few tens of metres or a few hundred metres, as is implemented for example by the DSRC (dedicated short range communication), CEN-DSRC, UNI-DSRC, IEEE 802.11p or WAVE (wireless access for vehicular environments) or ITS-G5 standards, including WLAN and Wifi®, Bluetooth® or also active and passive RFID (radio frequency identification) technologies.
The DSRC-OBU 7 is provided, in addition to its DSRC interface 6, with a further interface 8, which may be a radio interface according to the NFC (near field communication) standard, via which it can establish communication with a mobile telephone 9 (which may be, for example, NFC-enabled for this purpose). The mobile telephone 9 may in turn communicate with the central system 2 via a mobile network (public land mobile network, PLMN) 10 and possibly further data networks (not illustrated), for example the Internet. The interface 8 can alternatively also be produced by WLAN, Bluetooth or wired communication (for example USB, SD memory cards, or the like).
Here, the term “mobile telephone” 9 includes any type of communication device that can communicate in a mobile network 10 and that is additionally provided with an NFC interface 8, for example a cordless telephone, Smartphone, notebook PC or tablet PC, personal digital assistant (PDA), etc. The radio range of the NFC interface 8 is designed exclusively for the near-range, that is to say is limited to a few centimetres or a few tens of centimetres, such that the mobile telephone 9 has to be brought into the direct vicinity of the DSRC-OBU 7 in order to be able to carry out NFC radio communications via the NFC radio interface 8.
For the ticket charging, issuing and redemption methods presented hereinafter, the specified components, that is to say the central system 2, radio beacon(s) 4 and DSRC-OBU(s) 7, of the traffic telematics system 1 are provided as follows with electronic key pairs each formed of a public and a private key of a public/private key encryption method. As is known in the art, in the case of public/private key encryption methods, each subscriber receives two keys, specifically a public key, which is known to all other subscribers, and a private key, which is kept secret. A message—for example the electronic ticket 3 in this case—can be encrypted by a transmitter with the aid of the public key of the receiver and can then only be decrypted by the receiver using the private key thereof. Conversely, a message can be signed by a transmitter using the private key thereof. The receiver of the message can check the validity of the signing by the transmitter with the public key of the transmitter, that is to say can thus validate the signature of the transmitter.
For this purpose, the central system 2 has a public key PubK.CS and a private key PrivK.CS; each DSRC-OBU 7 has a public key PubK.OBU and a private key PrivK.OBU; and, at least in the first embodiment of the method, but not necessarily in the other embodiments of the method, each radio beacon 4 has a public key PubK.TRX and a private key PrivK.TRX. The public key PubK.TRX of the central system 2 is provided to the radio beacon 4 via a separate data path 11; or alternatively is transmitted together with an electronic ticket 3, as will be explained further below, in which case it is possible to dispense with the data path 11. For example, the data path 11 may be the Internet, an intranet or a mobile network, or also a physical transport path for a data carrier, over which the public key PubK.CS is transported from the central system 2 to the radio beacon 4.
The ticket charging, issuing and redemption method illustrated in
In the central system 2, a new electronic ticket 3 is generated and is provided for example with a unique ticket identification TK, for example a transaction ID or a timestamp. The issued ticket 3 is now signed in the central system 2 using the private central system key PrivK.CS and is encrypted using the public OBU key PrivK.OBU received previously in the ticket request 14. The signed and encrypted ticket 3 is sent back to the mobile telephone 9 via the mobile network 10 (step 18), possibly together with the public central system key Pubk.CS.
The mobile telephone 9 transmits the signed and encrypted ticket 3, received via the mobile interface 10, to the OBU 7 via the interface 8, via NFC (step 19) for example. In the OBU 7, the signed and encrypted ticket 3 is decrypted using the private OBU key PrivK.OBU (step 20). The now decrypted, yet signed ticket 3 can optionally be validated with the aid of the public central system key PubK.CS, that is to say the validity of the signature of the central system 2 can be checked (step 21). If the check fails, that is to say the signature is not authentic and therefore the ticket 3 is invalid, the ticket 3 can be rejected and/or the method terminated.
The OBU 7 then encrypts again (“re-encrypts”) the decrypted ticket 3 signed by the central system, specifically this time, in the embodiment shown in
In the radio beacon 4 the received, signed and re-encrypted ticket 3 is decrypted using the private radio beacon key PrivK.TRX (step 25), and the authenticity of its signature is then checked (validated) in step 26 with the aid of the public central system key PubK.CS: if the ticket 3 actually originates from the central system 2 (signature valid), the ticket 3 is then redeemed in a step 27. As explained, the redemption 27 may result in corresponding goods or services, an entrance authorisation, parking fee authorisation or toll fee authorisation, or the like.
Here, the public central system key PubK.CS can accompany the ticket 3 in all transmission steps 18, 19, 24, or alternatively may be transmitted once via the connection 11 from the central system 2 to the radio beacon 4.
Of course, some time may pass between the receipt 19 of the signed and encrypted ticket 3 from the mobile telephone 9 in the OBU 7 and the transmission 24 of the re-encrypted and signed ticket 3 from the OBU 7 to the ticket-redeeming radio beacon 4, during which time the ticket 3 is present in the OBU 7 and is transported thereby. Here, the decryption (step 20), the (optional) validation 21 and the new encryption 23 in the DSRC-OBU 7 take place in a secured hardware and/or software environment, for example in a cryptographically and/or physically secured “trusted element” in the OBU 7, or the OBU itself constitutes this “trusted element”. The central system 2 or the operator of the traffic telematics systems 1 can thus be sure that the key change, that is to say the decryption and re-encryption of the ticket 3, is performed correctly in the OBU 7. The ticket issuing of the central system 2, the mobile telephone 9 constituting a communication medium, and the ticket-redeeming radio beacon 4 are thus decoupled from one another in respect of their respective key pairs and require nothing more than the specified connections; if the data path 11 is also omitted and the public central system key PubK.CS is transported together with the ticket 3, there is in particular no direct connection between the ticket-issuing central system 2 and ticket-redeeming radio beacon 4.
The public central system key PubK.CS can again be transported here together with the ticket 3 or can be transmitted once via the data path 11 from the central system 2 to the radio beacon 4. In addition, the radio beacon 4 here also requires knowledge of the private central system key PrivK.CS, which can be provided likewise via the data path 11. Since the public and the private central system keys PubK.CS, PrivK.CS hardly change or do not change at all, a seldom or one-time transmission via the data path 11 is sufficient here.
The method of
The tickets 3 introduced into the electronic purse 32, for example in the form of a credit balance of the electronic purse 32 accumulated on the basis of the tickets, can be used subsequently, for example to carry out conventional prepaid DSRC fee transactions with a radio beacon 4, in order to debit the electronic purse 32, for example by means of a DSRC transaction via the DSRC interface 6, or to debit the electronic purse progressively. Alternatively, one or more “new” electronic tickets 3′ can be derived in the DSRC-OBU 7 from the credit balance or the introduced ticket(s) 3 of the electronic purse 32, said “new” electronic ticket(s) also being referred here as derived tickets 3′, which can then be redeemed at a radio beacon in accordance with the method variants illustrated in
The ticket 3, the account balance of the electronic purse 32 and/or the derived ticket(s) 3′ can optionally be signed in the OBU 7 using the private OBU key PrivK.OBU, whether for a conventional DSRC toll fee transaction or DSRC parking fee transaction or for the generation of signed, derived tickets 3′, which are redeemed at a radio beacon 4 in accordance with steps 23 to 31; the redeeming radio beacon 4 can then validate the authenticity of the tickets 3, 3′ on the basis of the public OBU key PubK.OBU.
The invention is not limited to the presented embodiments, but includes all variants and modifications that fall within the scope of the accompanying claims.
Number | Date | Country | Kind |
---|---|---|---|
13164396.7 | Apr 2013 | EP | regional |