WO2013004465A1 - Authentification de messages d'avertissement dans un réseau - Google Patents

Authentification de messages d'avertissement dans un réseau Download PDF

Info

Publication number
WO2013004465A1
WO2013004465A1 PCT/EP2012/061318 EP2012061318W WO2013004465A1 WO 2013004465 A1 WO2013004465 A1 WO 2013004465A1 EP 2012061318 W EP2012061318 W EP 2012061318W WO 2013004465 A1 WO2013004465 A1 WO 2013004465A1
Authority
WO
WIPO (PCT)
Prior art keywords
configuration
message
user
authentication data
notification
Prior art date
Application number
PCT/EP2012/061318
Other languages
English (en)
Inventor
Monica Wifvesson
Michael Liljenstam
John Mattsson
Karl Norrman
Original Assignee
Telefonaktiebolaget L M Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget L M Ericsson (Publ) filed Critical Telefonaktiebolaget L M Ericsson (Publ)
Priority to EP12727377.9A priority Critical patent/EP2727308B1/fr
Priority to US14/130,166 priority patent/US9467433B2/en
Priority to CN201280032071.9A priority patent/CN103650452B/zh
Publication of WO2013004465A1 publication Critical patent/WO2013004465A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]

Definitions

  • the present invention relates to a method and apparatus for authenticating warning messages in a network.
  • the invention relates to a method for configuring an authentication system.
  • MBMS Multicast Broadcast Multimedia System
  • CBS Cell Broadcast System
  • PWS Public Warning System
  • source origin authentication is necessary. This is usually achieved by adding a public key digital signature of the message to the message.
  • Examples of other mechanisms used include those based on pre-shared keys, and on hash-chains (e.g. IETF RFC 4082).
  • the receiver can verify that the signature is correct and hence deduce that the received message is also correct.
  • the receiver may further deduce that the message originates from the sender claiming to be the origin of the message.
  • Security features such as message authentication are normally handled by a two stage process by security protocols.
  • traffic is not protected between the sender and the receiver.
  • the sender and receiver agree on which security features are supported by each side. They negotiate which of these security features are to be used, together with possible parameters to configure each chosen security feature. For example, if a signature is to be added to a message, the sender and receiver could agree on which algorithm to use for the signature computation.
  • the sender of the message informs the receiver which security feature to use. In this situation the sender will have selected the security feature and its configuration from an assumed set of supported features or from a list of features and configurations previously obtained from the receiver. Once the security features are selected and configured, they have to be activated for messages sent from the sender to the receiver.
  • 3G and LTE telecommunication networks as defined by 3GPP (TS 33.102 v10.0.0, TS 33.401 v10.4.0).
  • the network sends a "security mode control message" to the terminal to instruct the terminal to start security processing of the messages. Before the security mode control message is sent the traffic is not protected.
  • IPsec IPsec (IETF RFC 4301 ), in which two peers run IKEv2 (RFC 4306) during the negotiation phase. When that is completed, traffic between the two peers starts to be integrity protected (if that feature was selected during the negotiation).
  • both the sender and the receiver of a message implement the functionality needed. For example, if the sender includes some control information in a message, the receiver is expected to be able to interpret the control information and take any action associated with it.
  • Another option is that there may be a mechanism in which the sender and receiver agree on which functionality will be supported, and after this they only include information relating to the agreed functionality in the messages.
  • a third option is that receivers are able to distinguish information elements which they do understand and can ignore those for which they have no support.
  • Systems are often designed and released in a step by step fashion. For example some functionality may be provided in a certain release, with more functionality being added in later releases. This is how telecommunication systems defined by 3GPP are handled.
  • the Public Warning System is a system for delivery of warning messages from a telecommunication network to terminals/user equipments, such as mobile telephones, laptops, and tablets.
  • the warnings are broadcast in certain areas.
  • a typical type of warning is a warning about an event such as tsunami or earthquake.
  • the terminal If the terminal completely ignores the signature field, the terminal is open to attacks. An attacker may inject false messages which the terminal will display to the user. This danger may lead to the development of a proprietary signature scheme which could then be implemented by some (but probably not all) terminals. Terminals could also be developed to interpret the signature field in some other proprietary way.
  • PWS Since PWS is a safety critical application it is crucial that users get the information provided by the system: this may possibly be even more important than the ability of the system to provide authentication of the messages.
  • the signature field is already included in the PWS warning messages, once the signature scheme is added to a 3GPP release, the problems with existing proprietary schemes and incorrect implementations described in the preceding paragraph will become reality. It will be noted that authentication of PWS messages is hence "always on", i.e. there is no negotiation phase which can be used to disable the feature.
  • the object of the present invention is to alleviate the above problems.
  • a device for communicating with a network comprising a communications unit for receiving data, a notification device for providing a notification to a user, and a control unit for controlling the operation of the communications unit and notification unit.
  • the communications unit is configured to receive an information message, and to receive security authentication data associated with the information message if such security authentication data is available.
  • the control unit is configured to operate in a first or second configuration. In the first configuration it ignores the security authentication data (if any) and instructs the notification unit to convey the notification to the user. In the second configuration, it verifies the information message on the basis of the security authentication data and instructs the notification unit to convey the notification to the user if the verification is successful.
  • the communications unit is configured to receive a configuration message indicating the configuration in which the control unit should operate, and the control unit is configured to change configuration if the indicated configuration is different to the current configuration.
  • the control unit may be initially configured to operate in the first configuration in one or more of the following situations: when the device is switched on for the first time; every time the device is switched on; when the device is restarted; when the device roams to a new network; when the device has been configured via a second configuration message; and following an interruption to communication.
  • the configuration message may indicate that the control unit should switch to the second configuration, so that from then on the notification is conveyed to the user if the information message is verified.
  • the control unit may be configured to authenticate the configuration message.
  • the configuration of the control unit may be stored in a configuration storage unit associated with the device.
  • the communications unit may be configured to receive one or more keys (e.g. public keys), which can be stored in a key storage unit associated with the device.
  • the control unit may be configured to use at least one of the one or more keys to verify the information message.
  • the communications unit may be configured to receive the one or more keys before the configuration message.
  • the one or more keys may be included in the configuration message, and the control unit may be configured to extract the one or more keys from the configuration message.
  • the configuration storage unit and/or key storage unit may be included in the device itself, or in a module such as SIM, USIM, or ISIM.
  • the module may be in the form of embedded UICC (eUICC) in ETSI SCP or a soft SIM implementation in a Trusted Execution Environment (TrE) also named MCIM. It could also be included in CSIM in 3GPP2.
  • eUICC embedded UICC
  • TrE Trusted Execution Environment
  • CSIM in 3GPP2.
  • the key storage unit and configuration storage unit may be the same entity.
  • the notification unit may comprise a display device, so that conveying the notification to the user may comprise displaying information contained in the information message.
  • the configuration message may include an indication of security information that should be displayed to the user.
  • the control unit may instruct the display device to display the security information to the user along with the information in that message in dependence on the indication in the configuration message.
  • security information may include for example the security level of the message, a timestamp, the originator of the message, etc.
  • the information message may be a Public Warning System message.
  • the control unit may be configured to authenticate the configuration message.
  • a serving node for use in a telecommunications network.
  • the serving node comprises a communications unit for sending data, a storage medium for storing data, and a control unit for controlling the operation of the communications unit and the storage medium.
  • the communications unit is configured to send a configuration message to user devices in the network, the configuration message including an indication as to whether or not the user devices should operate in a first configuration in which security authentication data associated with information messages sent subsequent to the configuration message is not processed before a notification is conveyed to a user, or a second configuration in which the security authentication data must be processed before a notification is conveyed to the user.
  • the communications unit may be configured to send one or more public keys to the user devices to enable the user devices to process the security authentication data. These public keys may be sent in the configuration message.
  • the configuration message may includes an indication of security information that should be displayed to the user.
  • a method for activating the use of security authentication data in a user device in a telecommunications network comprises receiving a configuration message and setting a configuration on the basis of an indication contained in the message.
  • received security authentication data associated with a received information message are ignored.
  • received security authentication data associated with a received information message are processed.
  • a method for operating a user device in a telecommunications network comprises receiving an information message and receiving security authentication data associated with the information message if such security authentication data is available.
  • the information message is processed in dependence on whether the device is configured in a first configuration or a second configuration.
  • the security authentication data if any, is ignored and a notification is conveyed to a user.
  • the second configuration the information message is verified on the basis of the security authentication data and a notification is conveyed to the user if the verification is successful.
  • the method further comprises receiving a configuration message indicating the configuration in which the control unit should operate. The configuration is changed if the indicated configuration is different to the current configuration.
  • a method for operating a serving node in a telecommunications network comprising sending a configuration message to user devices in the network, the configuration message including an indication as to whether or not the user devices should operate in a first configuration in which security authentication data associated with information messages sent subsequent to the configuration message is not processed before a notification is conveyed to a user, or a second configuration in which the security authentication data must be processed before a notification is conveyed to the user.
  • a computer program product comprising code adapted to be executed on a device in a telecommunications network.
  • the code is operable to cause the device to receive an information message and receive security authentication data associated with the information message if such security authentication data is available.
  • the code is further operable to process the information message in dependence on whether the device is configured in a first configuration or a second configuration. In the first configuration the security authentication data, if any, is ignored and a notification is conveyed to a user. In the second configuration the information message is verified on the basis of the security authentication data and a notification is conveyed to the user if the verification is successful.
  • the code is further operable to enable the device to receive a configuration message indicating the configuration in which the device should operate, and change configuration if the indicated configuration is different to the current configuration.
  • a computer program product comprising code adapted to be executed on a serving node in a telecommunications network, the code operable to cause the serving node to send a configuration message to user devices in the network, the configuration message including an indication as to whether or not the user devices should operate in a first configuration in which security authentication data associated with information messages sent subsequent to the configuration message is not processed before a notification is conveyed to a user, or a second configuration in which the security authentication data must be processed before a notification is conveyed to the user.
  • the invention also provides the computer program product described above, carried on a carrier medium such as RAM, ROM, EPPROM, flash memory, disk or similar.
  • the invention also provides a computer program comprising computer readable code which, when operated by a user device or serving node in a telecommunications network, causes the user device or serving node to carry out the methods described above.
  • the invention further provides a computer program product comprising a computer readable medium and a computer program as just described, wherein the computer program is stored on the computer readable medium.
  • a network device/network entity which comprises the configuration function that causes the network device to send the configuration message.
  • the network device may also be adapted to send the message authentication data and/or a warning message.
  • the message verification function and the configuration function may be computer programs which when run by the UE and the network device respectively causes them to perform the steps associated with the respective function as will be described more in detail below.
  • the computer programs can be stored in a computer readable medium/computer program product in the form of a memory such as a ROM, RAM, EEPROM, Flash or hard disk.
  • Figure 1 is a signalling diagram illustrating a basic concept for updating the configuration of a receiver
  • Figure 2 is a schematic illustration of functions used to implement the method shown in Figure 1 ;
  • FIG. 3 shows a PWS system architecture
  • Figure 4 is a flow diagram illustrating an example of the behaviour of a message verification function at a user device
  • Figure 5 is a flow diagram illustrating the display of a message by a user device
  • Figure 6 is a signalling diagram illustrating suitable signalling flow implementing the process flow of Figures 4 and 5;
  • Figure 7 is a flow chart illustrating exemplary behaviour of a message verification function when configuration is updated in response to receipt of a key
  • Figure 8 is a signalling diagram showing delivery of configuration information by a core network
  • Figure 9 is a signalling diagram showing delivery of configuration information by a push method.
  • Figure 10 is a signalling diagram showing delivery by a pull method
  • Figure 1 1 is a schematic illustration of the architecture of a user device for communicating with a network
  • Figure 12 is a schematic illustration of the architecture of a serving node for use in a network.
  • a system that enables the receiver of a message (e.g. UE/mobile terminal) to display that message (or send some other form of notification to a user) without needing to use received authentication information associated with the message to verify the authenticity of the message when the receiver is in a certain configuration.
  • the receiver may follow the new configuration and use authentication information associated with the messages to verify the authenticity of the messages and take relevant measures depending on the verification.
  • Figure 1 illustrates this in general terms.
  • a receiver (UE) 101 Initially (e.g. when the device is first switched on, or when it roams to a new network), a receiver (UE) 101 is in a first configuration in which it does not process authentication information.
  • a sender (e.g. a serving node) 102 sends a message 1 10 and message security authentication data to the receiver. Because the receiver 102 is configured not to process security authentication data it ignores the security authentication data 1 1 1 and processes the message. This sequence may be repeated some time later, with a message 1 12 and authentication data being sent to the receiver 101 , and the authentication data again being ignored 1 13 by the receiver.
  • a configuration function e.g. another serving node
  • sends a configuration message 1 14 to the receiver which causes the receiver to switch to a second configuration in which it processes security authentication data for all received messages from now on.
  • the receiver uses the authentication data to verify the authenticity of the message 1 16, and only present the message if the authenticity is confirmed.
  • Previously used schemes do not need to (and do not) include any authentication information with those messages sent before a decision is made that receivers should start using the selected security features. If the information provider were to use one of those methods in this situation, he would have to ensure that authentication information was not included with the messages transmitted before this decision is made. Legacy receivers may not be able to correctly receive, parse or use the message as intended, since they would expect the authentication information to be present.
  • PWS Public Warning System
  • FIG. 2 is a schematic illustration of a system for distributing a centrally controlled configuration for handling of one or more broadcast messages which reach a user device (UE) 201.
  • a key provisioning function 202 provisions the user device 201 with keys for authenticating broadcast messages.
  • the key provisioning function may be implemented in any suitable network node, for example an SGSN (Serving GPRS Support Node), MME (Mobility Management Entity), MSC (Message Switching Center), CBC (Cell Broadcast Center), NAF (Netwok Application Function), eNB, NodeB, RNC (Radio Nework Controller), BSC (Base Station Controller).
  • a broadcast message sender function 203 sends messages (possibly periodically) that carry authenticity information and/or integrity information.
  • the broadcast message sender function may be implemented in any network node, such as the BTS, BSC, RNC and eNodeB.
  • a message verification function 204 configured to filter messages based on the authenticity and/or integrity information carried in the messages and the provisioned key(s).
  • the message verification function can be implemented in the mobile equipment (ME) of the UE, or in a SIM or USIM module or other removable module such as ISIM, embedded UICC (eUICC) in ETSI SCP or a soft SIM implementation in a Trusted Execution Environment (TrE) also named MCIM.
  • MME mobile equipment
  • eUICC embedded UICC
  • TrE Trusted Execution Environment
  • the message verification function 204 is initially disabled (by default) to minimize the risk of the user missing any messages. Thus, all messages received by the message verification function are passed through.
  • an attack against the system is detected whereby falsified messages are sent to the user(s) and there arises a need to enforce authenticity and/or integrity checking of the messages.
  • a configuration function 205 interacts with the user device 201 to perform a verification configuration action to enable policy enforcement in the user's device, leading to blocking of further messages that fail validation of authenticity and/or integrity or other processing of security information.
  • the key provisioning could be performed at the same time as the verification configuration action, or any time before that.
  • FIG 3 is a schematic diagram of a system architecture suitable for providing security for PWS, as specified in document S3-1 10565.
  • the system is based on the Cell Broadcast System (CBS) defined in TS 23-041 , but it will be appreciated that any message broadcast system such as MBMS may also be appropriate.
  • the architecture includes an operator network (serving network) 310 which includes a Cell Broadcast Centre (CBC) 303 and MME 31 1 .
  • CBC Cell Broadcast Centre
  • MME 31 1 MME 31 1
  • a Cell Broadcast Entity (CBE) 312 provides the content of messages to be broadcast to the CBC 303.
  • the CBC node 303 implements the PWS Broadcast Message Sender Function 203 shown in Figure 2.
  • Messages are sent to a UE 201 via an E-UTRAN 313 (containing eNB 316), UTRAN 313 (containing NodeB 317 and RNC 318) or GERAN 314 (containing BTS 319 and BSC 320), for example.
  • the PWS messages are signed with a public key and integrity protected.
  • the public key is provided by the serving network 303 in response to each successful location area, routing area, or tracking area update. If the UE 201 discovers that it is missing the current key, it may also request it from the serving network 303.
  • Figure 4 is a flow chart illustrating the behaviour of the message verification function 204 associated with the UE 201 . It can be assumed that, by default, message verification is initially disabled and the UE operates in a "verification disabled" mode 401 .
  • a message is received 402 from a serving network, a check is made 403 to see if it is a configuration message. If it is not a configuration message (i.e. it is an information message) it is displayed to the user 404 immediately.
  • other forms of notification may be sent to the user, for example an audible notification or a tactile movement.
  • the display of information is described by way of example. In some embodiments it is possible that both an audible and/or tactile notification and a display of information may be employed.
  • the message is a configuration message then a check is made 405 to determine what configuration is indicated therein. If the indicated configuration is for verification to be disabled then the verification disabled mode 401 should be maintained and the UE waits to receive the next message 402. If the indicated configuration is that verification should be enabled verification then the UE switches over into "verification enabled" mode 406 and waits to receive the next message 407. It will be appreciated that the configuration message itself should be authenticated to the user. This can be done using any suitable system such as a public key signature.
  • a check 408 is again made to determine whether it is a configuration message. If so, then the configuration indicated is again checked 405 and the UE returned to verification disabled mode 401 or maintained in verification enabled mode 406, depending on the indicated configuration.
  • the message is not a configuration message and verification is enabled (i.e. it is an information message containing information to be displayed), then checks are made to authenticate the message 409 and confirm its integrity 410. If either of these checks is failed then the message is discarded 41 1 . If both are passed then the message is displayed 412.
  • a configuration message may also include instructions to change the information displayed to the user in all future messages.
  • stored update information is amended 413 in the UE to enable or disable display of various parameters such as the level of security, timestamp or originator of the message. These can be set regardless of the current mode of the UE.
  • Figure 5 is a flow chart illustrating how the display message functions 404, 412 operate, depending on the update information stored in the UE. If security level 501 is enabled it is added to the message content 502; if timestamp 503 is enabled then it is added to the message content 504; if the originator is enabled 505 then this information is added to the message content 506. The message, now possibly including the additional security-related content, is then displayed 507.
  • a key provisioning function 601 (e.g. in the operator network 310) provisions the MME 31 1 with a public key for the PWS service 602.
  • the UE 201 registers with the operator network (including via location, routing, tracking services) it carries out an Area Update Procedure.
  • the PWS public key is provided to the UE 201 as part of this procedure 603.
  • a configuration message 607 is sent from the policy control function 205 to the UE 201.
  • Subsequent PWS warning messages 608, 609 are then authenticated 610 by the UE before they are displayed 61 1 .
  • the approach can also be used to switch UEs to a configuration in which they no longer process authentication information (as shown in Figure 4). This can be useful if it turns out that a large set of devices turns out to be incorrectly implemented and discard valid warning messages.
  • first actions 602, 603 shown in Figure 6 result in key provisioning to the UE 201. It will be appreciated that key provisioning could alternatively be performed at a later time, or even as part of the verification configuration action 607. Key provisioning could be performed by different functions or nodes, such as for example the MME, ANDSF (Access Network Discovery and Selection Function) server, or eNB. Other suitable nodes will also be apparent to one skilled in the art.
  • key provisioning to cause the message verification function 204 in the UE 201 to enable verification - i.e., the key provisioning itself is effectively the verification configuration action. This can be understood with reference to Figure 7. As before, the verification function 204 is initially in verification disabled mode.
  • a message When a message is received 701 , it is checked 702 to see whether it is a key provisioning message or information message. If it is an information message, it is displayed to the user 703 as before. If it is a key provisioning message the key is saved at the UE 201 , and the verification function 204 is switched to verification enabled mode. Subsequent incoming messages 704 are checked 705 to see if they are configuration messages. If they are configuration messages and they contain an indication that verification should not be implemented 706 then the verification function 204 is returned to verification disabled mode. If a message contains information for display then it is authenticated 707 and its integrity checked 708 before being displayed 709 or discarded 710 as before.
  • the configuration details could be delivered to the UE 201 by an element in the core network (e.g. MME, MSC or SGSN) using Non-Access Stratum (NAS) protocols.
  • NAS Non-Access Stratum
  • a new optional information element (IE) could be added in the NAS protocol to any NAS procedure from the network towards the UE. Suitable examples include Attach Accept, Routing Area Update Accept, Location Update Accept, Tracking Area Update Accept, Security Mode Command. Figure 8 illustrates one example of such a delivery mechanism.
  • the figure is a signalling diagram for an attachment procedure to an MME handover in a system containing a UE 201 , eNodeB 316, MME 801 , EIR 802, Serving GW and PDN GW 803, 804, PCRF 805 and HSS 806, where the UE 201 has previously been attached to an old MME 801 .
  • An Attach Request 810 is sent from the UE 201 to the eNodeB 316, and this is forwarded 81 1 to the new MME 31 1 .
  • the new MME 31 1 sends an Identification Request 812 to the old MME 801 , which returns an identification response 813.
  • the new MME sends an Identity Request 814 to the UE 201 , which returns an Identity Response 815.
  • the UE 201 and new MME 31 1 are then authenticated 816 to each other, using authentication information provided by the HSS 806. Once the authentication procedure is complete, the new MME 31 1 sends an Attach Accept message 817 to the UE 201 , and it is this Attach Accept message that contains an IE including the configuration details for use by the verification function 204 of the UE 201. This approach also makes it possible to deliver the configuration to roaming users.
  • RRC layer in an eNodeB Another option is to deliver the configuration details by the Radio Access Layer (known as the RRC layer in an eNodeB).
  • the RRC layer in the eNode B inserts configuration details for the selected MME node into a RRCConnectionSetup message sent to the UE.
  • the RRC layer may insert the new configuration into some other message from the network to the UE. This again makes it possible to deliver the configuration to roaming users.
  • the UE may initiate communication, e.g. using an IP-tunnel, with an ANDSF (Access Network Discovery and Selection Function) server for operator preferred access network discovery.
  • ANDSF Access Network Discovery and Selection Function
  • the UE After communicating with the ANDSF, the UE may be provided with updated inter-system policy and information about available access networks in the vicinity of the UE. Configuration details could also be provided by the ANDSF to the UE. Even when the UE is roaming in a visited PLMN, it would be possible for the UE to use DNS lookup to discover the IP address of V-ANDSF in order to access the ANDSF in a visited PLMN, as explained in TS 24.302.
  • the configuration is delivered to the UE 201 by the CBC 303.
  • a further option is for the configuration details to be passed to the UE using a "push" method as shown in Figure 9.
  • a procedure 901 such as an Attach procedure, Location Update, procedure, Routing Area Update procedure or Tracking Area Update procedure
  • the HLR/HSS 806 triggers 803 the Configuration Function 208 to send the configuration details to the UE in an OMA DM bootstrap message in a WAP Push message 904 using SMS.
  • GBA Push would be even more secure to use in the push method, as described in TS 33.223 and TS 33.224. This approach makes it possible to deliver the configuration information to roaming users.
  • the serving network 900 may be a home network or a visited network.
  • a different approach would be to deliver the configuration information by a "pull" method, as shown in Figure 10.
  • a procedure 901 such as an Attach procedure, Location Update, procedure, Routing Area Update procedure or Tracking Area Update procedure
  • the HLR/HSS 806 causes the Configuration Function 205 to send the UE 1004 an OMA DM bootstrap message in a WAP Push message using SMS.
  • the UE could also be preconfigured by the home operator with the IP address of the network server in which the Configuration Function resides.
  • the configuration could be delivered to the USIM via the device using the OTA protocol from the OTA system. If the security authentication information is verified by the ME of the UE, then the ME has to retrieve the configuration from the USIM.
  • Figure 1 1 is a schematic illustration of the structure of a user device 1 100 for use in a network.
  • the user device is suitable for use as the devices 101 , 201 described above.
  • the device includes a communications unit 1 101 for exchanging data with other entities in the network, a storage unit 1 102 for storing data, a control unit 1 103 and a notification unit 1 104 for conveying a notification to a user.
  • the notification unit 1 104 may include a display device.
  • the storage unit 1 102 may be configured to store keys used to authenticate information messages, and/or to store the configuration in which the device is operating at any given time. It will be appreciated that keys and the configuration need not be kept in the same storage unit.
  • the storage unit 1 102 and/or control unit 1 103 may be incorporated into the ME, or may be incorporated into a removable module 1 105 such as SIM or USIM.
  • removable modules include ISIM (TS 31 .103 v.10.1 .0), an embedded UICC (eUICC) in ETSI SCP (Draft ETSI TS 103 383 vO.0.3 or SCPREQ(1 1 )0072R1 1_Draft_Embedded_UICC_Requirements_Specification) or a soft SIM implementation in a Trusted Execution Environment (TrE) also named MCIM (TR 33.812 v.9.2.0), or CSIM in 3GPP2.
  • TrE Trusted Execution Environment
  • FIG 12 is a schematic illustration of a serving node 1200 suitable for providing a configuration function 103, 205.
  • the serving node comprises a communications unit 1201 for exchanging data with other entities in the network, a storage unit 1202 and a control unit 1203.
  • the systems described above reduce the risk of messages being erroneously blocked by verification (for example as a result of technical errors in key provisioning or in the transmission leading to erroneously failed verification).
  • a system is deployed while the authenticity and integrity information has not yet been fully specified.
  • the approach described avoids performing any verification action until a need has clearly developed, to avoid misinterpreting spurious content in authenticity and integrity fields.
  • the system addresses the practical problems resulting from deployment of only partially specified features, as in the case of PWS message authentication.
  • message verification during system operation, for example, such that verification is only required if there is a significant threat against the system - such as when an attack has been detected previously.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un dispositif (101) destiné à communiquer avec un réseau. Le dispositif (101) comprend une unité de communication pour recevoir des données, un dispositif de notification pour fournir une notification à un utilisateur, et une unité de commande pour commander le fonctionnement de l'unité de communication et de l'unité de notification. L'unité de communication est configurée pour recevoir un message d'informations (110, 112, 115) et recevoir des données d'authentification de sécurité (110, 112, 115) associées au message d'informations si de telles données d'authentification de sécurité sont disponibles. L'unité de commande est configurée pour fonctionner dans une première ou une seconde configuration. Dans la première configuration, elle ignore les données d'authentification de sécurité, (111, 113), et donne l'instruction à l'unité de notification d'acheminer la notification vers l'utilisateur. Dans la seconde configuration, elle vérifie le message d'informations (116) sur la base des données d'authentification de sécurité et donne l'instruction à l'unité de notification d'acheminer la notification vers l'utilisateur si la vérification est réussie. L'unité de communication est configurée pour recevoir un message de configuration (114) indiquant la configuration dans laquelle l'unité de commande devrait fonctionner, et l'unité de commande est configurée pour changer de configuration si la configuration indiquée est différente de la configuration courante.
PCT/EP2012/061318 2011-07-01 2012-06-14 Authentification de messages d'avertissement dans un réseau WO2013004465A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP12727377.9A EP2727308B1 (fr) 2011-07-01 2012-06-14 Authentification de messages d'avertissement dans un réseau
US14/130,166 US9467433B2 (en) 2011-07-01 2012-06-14 Authentication of warning messages in a network
CN201280032071.9A CN103650452B (zh) 2011-07-01 2012-06-14 认证网络中的警报消息的方法和设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161503806P 2011-07-01 2011-07-01
US61/503,806 2011-07-01

Publications (1)

Publication Number Publication Date
WO2013004465A1 true WO2013004465A1 (fr) 2013-01-10

Family

ID=46275840

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/061318 WO2013004465A1 (fr) 2011-07-01 2012-06-14 Authentification de messages d'avertissement dans un réseau

Country Status (4)

Country Link
US (1) US9467433B2 (fr)
EP (1) EP2727308B1 (fr)
CN (1) CN103650452B (fr)
WO (1) WO2013004465A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2785003A1 (fr) * 2013-03-28 2014-10-01 Nokia Solutions and Networks Oy Procédés, appareils et produits de programme informatique permettant d'améliorer des systèmes d'alerte au public
EP2785002A1 (fr) * 2013-03-28 2014-10-01 Nokia Solutions and Networks Oy Étude géographique pour améliorer la sécurité des systèmes d'avertissement public
WO2014208033A3 (fr) * 2013-06-28 2015-03-19 Nec Corporation Découverte sécurisée pour une communication de service de proximité

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2335180B1 (fr) * 2008-10-08 2019-04-10 Nokia Technologies Oy Contrôle d'accès à une mémoire
WO2016043567A1 (fr) * 2014-09-19 2016-03-24 Lg Electronics Inc. Procédé et appareil pour transmettre/recevoir un message mbsp dans un système d'accès sans fil
US9860266B2 (en) * 2015-10-26 2018-01-02 Blackberry Limited Preventing messaging attacks
US10432461B2 (en) 2015-12-04 2019-10-01 T-Mobile Usa, Inc. Peer-to-peer distribution of radio protocol data for software defined radio (SDR) updates
US10257165B2 (en) 2016-09-30 2019-04-09 T-Mobile Usa, Inc. Dynamic provisioning of a firewall role to user devices
US10616776B2 (en) 2016-09-30 2020-04-07 T-Mobile Usa, Inc. Dynamic provisioning of a gateway role to user devices
US10362482B2 (en) * 2016-12-21 2019-07-23 T-Mobile Usa, Inc. Network operation and trusted execution environment
US10652256B2 (en) * 2017-06-20 2020-05-12 International Business Machines Corporation Real-time active threat validation mechanism for vehicle computer systems
CN110213252B (zh) * 2018-07-13 2022-03-25 Oppo广东移动通信有限公司 通信方法、终端设备和网络设备
US11050735B2 (en) 2018-08-23 2021-06-29 International Business Machines Corporation Customizable authentication system
CN111866872B (zh) * 2019-04-29 2023-06-02 华为技术有限公司 一种通信方法及装置
TWI780372B (zh) * 2019-10-30 2022-10-11 緯創資通股份有限公司 設備佈建系統及其方法
WO2021165111A1 (fr) * 2020-02-20 2021-08-26 Telefonaktiebolaget Lm Ericsson (Publ) Notification de changement de clé pour authentification et gestion de clé d'applications

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006098552A1 (fr) * 2005-03-17 2006-09-21 Electronics And Telecommunications Research Institute Procede permettant la negociation de fonctions se rapportant a la securite d'une station d'abonne, dans un systeme internet portable sans fil
WO2007110094A1 (fr) * 2006-03-27 2007-10-04 Telecom Italia S.P.A. Système de mise en application de politiques de sécurité sur des dispositifs de communications mobiles

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6977909B2 (en) * 2000-01-19 2005-12-20 Phonepages Of Sweden, Inc. Method and apparatus for exchange of information in a communication network
US20020013831A1 (en) * 2000-06-30 2002-01-31 Arto Astala System having mobile terminals with wireless access to the internet and method for doing same
ATE391385T1 (de) * 2003-07-11 2008-04-15 Ibm Verfahren und system zur benutzerauthentifizierung in einer benutzer- anbieterumgebung
IL176275A0 (en) * 2006-06-13 2007-05-15 Celltick Technologies Ltd Cellular emergency notification service
CN102440012B (zh) * 2009-04-15 2014-01-01 华为技术有限公司 接收公共预警系统pws消息的方法、装置和系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006098552A1 (fr) * 2005-03-17 2006-09-21 Electronics And Telecommunications Research Institute Procede permettant la negociation de fonctions se rapportant a la securite d'une station d'abonne, dans un systeme internet portable sans fil
WO2007110094A1 (fr) * 2006-03-27 2007-10-04 Telecom Italia S.P.A. Système de mise en application de politiques de sécurité sur des dispositifs de communications mobiles

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Public Warning System (PWS) requirements (Release 11)", 3GPP STANDARD; 3GPP TS 22.268, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V11.1.0, 1 April 2011 (2011-04-01), pages 1 - 13, XP050476755 *
HUAWEI ET AL: "Security features of PWS", 3GPP DRAFT; S3-110365, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Chengdu; 20110411, 2 April 2011 (2011-04-02), XP050526635 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2785003A1 (fr) * 2013-03-28 2014-10-01 Nokia Solutions and Networks Oy Procédés, appareils et produits de programme informatique permettant d'améliorer des systèmes d'alerte au public
EP2785002A1 (fr) * 2013-03-28 2014-10-01 Nokia Solutions and Networks Oy Étude géographique pour améliorer la sécurité des systèmes d'avertissement public
WO2014208033A3 (fr) * 2013-06-28 2015-03-19 Nec Corporation Découverte sécurisée pour une communication de service de proximité
CN105359554A (zh) * 2013-06-28 2016-02-24 日本电气株式会社 基于邻近服务通信的安全发现

Also Published As

Publication number Publication date
CN103650452A (zh) 2014-03-19
EP2727308B1 (fr) 2019-08-07
CN103650452B (zh) 2016-11-02
US20140150064A1 (en) 2014-05-29
US9467433B2 (en) 2016-10-11
EP2727308A1 (fr) 2014-05-07

Similar Documents

Publication Publication Date Title
EP2727308B1 (fr) Authentification de messages d'avertissement dans un réseau
CN110945886B (zh) 无线通信网络中检测漫游活动的反引导的方法和系统
US11863982B2 (en) Subscriber identity privacy protection against fake base stations
EP2932676B1 (fr) Authentification de réseaux mobiles terrestres publics sur des stations mobiles
US11178547B2 (en) Identity-based message integrity protection and verification for wireless communication
CN113940106A (zh) 用于处理封闭接入组相关过程的方法和系统
US11071043B2 (en) Enhanced handling on forbidden PLMN list
EP3652982A1 (fr) Procédé et système de caractéristiques de trafic d'un plan d'utilisateur et sécurité de réseau
CN110786031A (zh) 用于5g切片标识符的隐私保护的方法和系统
US9661534B2 (en) Operation of a serving node in a network
CN111788839A (zh) 用户身份隐私保护和网络密钥管理
US20190068651A1 (en) Cellular security framework
KR20100054178A (ko) 이동 통신 시스템에서 단말 보안 능력 관련 보안 관리 방안및 장치
US11895490B2 (en) Mobile cellular networks authenticated access
US9161221B2 (en) Method, apparatus and computer program for operating a user equipment
Ghannam et al. User-targeted denial-of-service attacks in LTE mobile networks
JP6651613B2 (ja) ワイヤレス通信
WO2015056037A1 (fr) Gestion de contrôle d'encombrement spécifique à une application
US20130185372A1 (en) Management of user equipment security status for public warning system
US20220386104A1 (en) On-device physical sim to esim conversion

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12727377

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012727377

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14130166

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE