1.1. Security and Privacy Overview
Security:
- A security requirement of a MBMS User Service is to be able to securely transmit data to a given set of users. In order to achieve this, there needs to be a method of authentication, key distribution and data protection for a MBMS User Service.
- To prevent unauthorized reception of multicast data, multicast transmission may be secured.
- To prevent injection of malicious content into the network MBMS should be able to authenticate the content provider and verify the integrity of the data received from the content provider.
- It is required that a USIM is present in the UE to receive MBMS services.
- MBMS data can be protected by encryption. This encryption will be applied end-to-end between the BM-SC and the UEs.
- Ciphering at the RAN or core network level is not required. Therefore:
- in Iu mode, the SGSN will not perform a RANAP security mode control procedure for MBMS bearers at the Iu interface;
- in A/Gb mode, the SGSN will not apply ciphering to LLC frames to be transmitted via MBMS point‑to‑multipoint bearers.
- It shall be possible to ensure that only those users who are entitled to receive a specific MBMS service may do so. It should be possible to choose whether a given MBMS service is to be delivered with or without ensured group security
- Any user modifiable MBMS service data shall only be modified by the authenticated user.
Privacy:
- Third parties and VASP should not be aware about user IDs for MBMS subscriptions unless explicitly allowed by the operator.
1.2. Authentication and Authorization
Content Provider - Authentication and Authorization
- MBMS should be able to identify and authenticate the content provider prior to receiving control or data from it.
- A content provider may request to provide a multicast or broadcast service using MBMS possibly stating desired QoS, geographical areas and other service-related parameters.
- MBMS shall be able to authorize this service provision with the requested parameters prior to service initiation.
User - Authentication and Authorization
- MBMS shall be able to authenticate and authorize users before joining to multicast groups (i.e. receive MBMS multicast services).
- The Membership function within the BM-SC is used to verify the subscription information in MBMS Multicast Mode.
- A UE is authenticated and authorized such that only legitimate users are able to participate in an MBMS User Service.
- When the UE establishes (or releases) the MBMS bearer(s) to receive an MBMS User Service, it is authenticated and authorized.
User – Authorization
- Upon reception of an IGMP (IPv4) or MLD (IPv6), Join message for an IP multicast address allocated to MBMS services, the GGSN shall request authorization of the user for this multicast MBMS bearer service (identified by the PDP context over which the IGMP join is received).
- The GGSN shall support pre-configuration of a BM-SC or Gmb proxy server for authorization purposes to which the request shall be sent.
- The GGSN may support a list of pre-configured BM-SC servers based on the MBMS bearer service requested, for authorization purposes.
- Upon receipt of an MBMS UE Context Establishment Request for a user who has not already been authorized for the MBMS bearer service, the GGSN shall request authorization of the user for this service.
1.3. Authentication and Authorization in HTTP procedures
The User Authentication to the BM-SC is using HTTP digest with bootstrapped security associations:
- When the UE uses HTTP protocol towards the BM-SC, the UE is authenticated with HTTP digest.
- The BM-SC shall implement initiation of bootstrapping and bootstrapping renegotiation procedures
- The Ua interface procedures shall use MRK.
HTTP digest authentication:
- HTTP digest is run between BM-SC and ME. When the UE initiates an HTTP procedure towards the BM-SC, HTTP digest authentication shall be used for mutual authentication.
- The MBMS authentication procedure is based on the general user authentication procedure over Ua interface that is specified in clause
- The BM-SC will act as a NAF according to TS 33.220. (NAF= Network Application Function)
- Along with the GBA-keys, the BSF shall send the IMPI of the user to the BM-SC.
- GBA= Generic Bootstrapping Architecture
- BSF=Bootstrapping Server Function
The following adaptations apply to HTTP digest:
- B-TID (Bootstrapping Transaction Identifier) as specified in TS 33.220 is used as username;
- MRK (MBMS Request Key) is used as password.
- All HTTP procedures within this specification including the associated delivery procedures in TS 26.346 shall be integrity protected with HTTP digest
Authentication and authorization in MBMS bearer establishment
- Authentication of the UE during MBMS bearer establishment relies on the authenticated point-to-point connection with the network, which was set up using network security
- Authorization for the MBMS bearer establishment happens by the network making an authorization request to the BM-SC to ensure that the UE is allowed to establish the MBMS bearer(s) corresponding to an MBMS User Service.
1.4. Security – MBMS Key Management Overview
- Like any service, the keys that are used to protect the transmitted data in a MBMS User Service should be regularly changed to ensure that they are fresh. This ensures that only legitimate users can get access to the data in the MBMS User Service.
- In particular frequent re-keying acts as a deterrent for an attacker to pass the MBMS keys to others users to allow those other users to access the data in an MBMS User Service.
- The BM-SC is responsible for the generation and distribution of the MBMS keys to the UE.
- A UE has the ability to request a key when it does not have the relevant key to decrypt the data. This request may also be initiated by a message from the BM-SC to indicate that a new key is available.
Some abbreviations in MBMS Key Management:
1. MRK = MBMS Request Key (This key is to authenticate the UE to the BM-SC when performing key requests etc.)
2. MUK = MBMS User Key: The MBMS user individual key that is used by the BM-SC to protect the point to point transfer of MSK's to the UE.
3. MSK = MBMS Service Key (The MBMS Service key that is securely transferred (using the key MUK) from the BM-SC towards the UE. The MSK is not used directly to protect the MBMS User Service data (see MTK).)
4. MTK = MBMS Traffic Key (A key that is obtained by the UICC or ME by calling a decryption function MGV-F with the MSK. The key MTK is used to decrypt the received MBMS data on the ME.)
- Note: When a UICC is used, the keys MSK and MUK may be stored within the UICC or the ME depending on the UICC capabilities. When a SIM card is used, the keys MSK and MUK are stored within the ME.
- BSF = Bootstrapping server function
- MGV-F = MBMS key Generation and Validation Function
- MGV-S = MBMS key Generation and Validation Storage
The following rules apply for MBMS key management: (MSK + MTK + MUK)
MUK and MRK:
- The sub-function “Key Request function” in BM-SC is responsible for retrieving GBA keys from the BSF (Bootstrapping server function), deriving MUK and MRK from GBA keys
- MBMS Request Key is to authenticate the UE to the BM-SC when performing key requests etc. via Ua interface
MSK:
- MSKs and MTKs are managed at the MBMS User Service Level.
- The BM-SC controls the use of the MBMS Service Keys (MSKs) to secure the different RTP sessions and FLUTE channels.
- The delivery of MSKs is secured with user specific MBMS User Key (MUK)
- MSKs are used to protect the delivery of MBMS Transport Keys (MTKs)
- MSKs shall be used to protect MTKs of only one RTP session or FLUTE channel. It shall be possible to update the MSKs during an RTP session or FLUTE channel to enhance the security.
- MSKs within one Key Group shall be used to protect MTKs of only one RTP session or FLUTE channel. To allow smooth transition from
MTK:
- MTKs are used to secure the RTP sessions and FLUTE channels.
- The use of the same MTK within two different RTP sessions is not allowed according to RFC3711.
- It shall be possible to update the MTKs during an RTP session or FLUTE channel to enhance the security.
MSK identification
- Every MSK is uniquely identifiable by its Key Domain ID and MSK ID (N/A Here)
MTK identification
- Every MTK is uniquely identifiable by its Key Domain ID, MSK ID and MTK ID (N/A Here)
Some of the rules are illustrated in figures and examples below.
- The usage of MSKs and MTKs applied to a RTP session or FLUTE channel (i.e. usage of MSKs and MTKs for one Key group) is depicted in figure below shows an example of the usage of MSKs and MTKs for three RTP sessions. In particular it shows that MSKs and MTKs of one Key Group are used to protect exactly one RTP session.
- Figure below: MBMS key hierarchy: usage of MSKs and MTKs for three separate RTP sessions
- Figure below: MBMS key hierarchy: usage of MSKs and MTKs within one RTP session or FLUTE channel in one key group
§ According to TS 22.246 there exist MBMS User Services with shared and non-shared Transport Services.
§ In case two MBMS User Services share an MBMS Transport Service, they also share one or more RTP sessions or FLUTE channels carried in the Transport Service.
§ In this case, it shall be possible for the MBMS User Services to share one or more MSKs and MTKs of the Key Groups that are used to protect the MBMS data.
1.5. MBMS Security Architecture
- Nearly all the security functionality for MBMS, except for the normal network bearer security, resides in either the BM-SC or the UE.
- The UE and the BM-SC use GBA (GAA= Generic Authentication Architecture in 33.220) to establish shared keys that are used to protect the point-to-point communication between the UE and the BM-SC.
BM-SC is responsible for
- establishing shared secrets with the UE using GBA,
- authenticating the UE with HTTP digest authentication mechanism,
- registering and de-registering UEs for MBMS User Services,
- generating and distributing the keys necessary
§ for MBMS security to the UEs with MIKEY protocol (MIKEY= Multimedia Internet KEYing)
§ for applying the appropriate protection to data that is transmitted as part of a MBMS User Service.
§ The BM-SC also provides the MBMS bearer authorization for UEs attempting to establish MBMS bearer.
§ The BM-SC also verifies whether a user is authorized to register and receive keys for a MBMS User Service.
§ For MBMS Multicast Mode this authorization is done with the help of Membership function in the BM-SC.
§ For MBMS Broadcast Mode this authorization is done without the help of Membership function because the Membership function is only defined in the context of MBMS Multicast Mode in TS 23.246.
UE is responsible for
§ establishing shared secrets with the BM-SC using GBA,
§ registering to and de-registering from MBMS User Services,
§ requesting and receiving keys for the MBMS User Service from the BM-SC and also
§ using those keys to decrypt the MBMS data that is received.
MBMS imposes the following requirements on the MBMS capable elements:
- (BM-SC) A BM-SC shall support using both GBA_ME and GBA_U keys to enable both ME based and UICC based MBMS key management, respectively.
- (UICC) A UICC that contains MBMS key management functions shall implement GBA_U;
- (ME) A ME that supports MBMS shall implement GBA_U and GBA_ME, and shall be capable of utilising the MBMS key management functions on the UICC as well as providing MBMS key management functions itself;
- GBA_U = GBA with UICC-based enhancements
- GBA_ME = ME-based GBA
1.6. Security – BM-SC Sub-Function for MBMS Security
The BM-SC has the following sub-functions related to MBMS security, see figure below
- Key Management function in BM-SC: includes two sub-functions: Key Request function and Key Distribution function.
- The BSF (BSF= Bootstrapping server function) is a part of GBA (GBA= Generic Bootstrapping Architecture in TS 33.220).
- Figure below gives an overview of the network elements involved in MBMS from a security perspective.
http://docs.google.com/View?id=ddh56dhg_153g328jvg4
Key Request function in BM-SC Key Management Function: The sub-function is responsible for
- retrieving GBA keys from the BSF (Bootstrapping server function), deriving MUK and MRK from GBA keys,
- performing MBMS User Service Registration, Deregistration and MSK request procedures and related user authentication using MRK,
- providing MUK to Key Distribution function, performing authorization check.
- The sub-function implements the following functions and procedures:
- Bootstrapping initiation
- Bootstrapping re-negotiation
- HTTP digest authentication
- MRK derivation
- MBMS User Service Registration procedure
- MBMS User Service Deregistration procedure
- MSK request procedure
Key Distribution function in BM-SC Key Management Function: The sub-function is responsible for
- retrieving MUK from Registration function,
- generating and distributing MSKs and MTKs to the UE,
- providing MTK to Session and Transmission function.
- The sub-function implements the following security procedures:
- MSK delivery procedure
- MTK delivery procedure
- BM-SC solicited pull procedure
Session and Transmission function in BM-SC: The sub-function is responsible for
- performing protection of data with MTK (encryption and/or integrity protection).
- The sub-function implements the following security procedures:
- Protection of streaming data
- Protection of download data
Membership function:
- The Membership function is used to verify if a user is authorized to register, receive keys or to establish a MBMS bearer for MBMS Multicast Mode.
1.7. Security – Using GBA for MBMS (MRK and MUK)
- GBA (Generic Bootstrapping Architecture) in TS 33.220 is used to agree keys that are needed to run an MBMS User Service.
- If the Service Announcement indicates that protection of the MBMS User Service is applied, then the UE needs to share GBA-keys with the BM-SC.
- If no valid GBA-keys are available at the UE, the UE shall perform a GBA run with the BSF of the home network as described within TS 33.220.
- The BM-SC will act as a NAF (Network Application Function) according to TS 33.220. Along with the GBA-keys, the BSF shall send the IMPI of the user to the BM-SC.
- When the UE has bootstrapped, it will use a new B-TID over the Ua reference point. The IMPI is used in the BM-SC to bind the old and the new B-TID together.
- The use of
- It is possible for operators to explicitly prohibit the use of SIMs for MBMS access based on policy configuration at the BSF.
The MSKs for an MBMS User Service shall be stored on
- either the UICC, if the UICC is capable of MBMS key management,
- or the ME, if the UICC is not capable of MBMS key management or a SIM card is used.
- Storing the MSKs on the UICC requires a UICC that contains the MBMS management functions.
- As a result of a GBA_U run, the BM-SC will share a key Ks_ext_NAF with the ME and share a key Ks_int_NAF with the UICC.
- In case the UICC supports MBMS, then this key Ks_int_NAF is used by the BM-SC and the UICC as the key MUK (MBMS User Key) to protect MSK (MBMS Service Key) deliveries to the UICC. The key Ks_ext_NAF is used as the key MRK (MBMS Request Key) within the protocols.
- In case the UICC does not support MBMS then the key Ks_int_NAF can not be used for ME based key management, but the key Ks_ext_NAF shall be used as MUK and the key MRK is derived from the key Ks_ext_NAF by the BM-SC and the ME as specified in Annex F of TS 33.246.
- A run of GBA_ME or
- Both the BM-SC and the ME use the key Ks_NAF as MUK.
- The key MRK is derived from the key Ks_NAF by the BM-SC and the ME as specified in Annex F of TS 33.246.
- The key MUK is used to protect MSK deliveries to the ME. The key MRK is used to authenticate the UE towards the BM-SC within the protocols as described within TS 33.246.
- The MUK and MRK are identified by the combination of B‑TID and NAF‑ID (without the Ua security protocol identifier) in the UE and by B‑TID in the BM-SC
- In the UE, two different MUKs, i.e. the last generated and the last successfully used, are used to guarantee that the UE and the BM-SC share always one MUK.
- The last generated MUK is replaced immediately after when a new MUK is generated and
- The last successfully used MUK is updated after the successful reception of the MIKEY message, which is protected using the last generated MUK.
1.8. Security – UE Architecture for MBMS Security
- It is assumed that the UE includes a secure storage (MGV-S).
- This MGV-S may be realized on the ME or on the UICC.
- MGV-S stores the MBMS keys
- In particular in ME based key management, it shall be ensured that the keys are not exposed to unprotected parts of the ME when they are transmitted from the UICC to the MGV-S or during the key derivations.
- The MGV-F is implemented in a protected execution environment to prevent leakage of security sensitive information such as MBMS keys.
- MGV-F performs the functions that should not be exposed to unprotected parts of the ME.
- MGV-S = MBMS key Generation and Validation Storage
- MGV-F = MBMS key Generation and Validation Function
Overview of ME-based and UICC-based key managements in UE is described in figures below.
1). For ME based key management:
- All MBMS keys (MUK, MRK, MSK and MTK) shall be deleted from the ME when a different UICC or SIM is inserted.
- Therefore the ME needs to store in non-volatile memory the last inserted UICC or SIM identity to be able to compare that with the used UICC or SIM identity at card insertion and power on.
- All MBMS keys (MRK, MSK and MTK) may be deleted from the ME when the ME is powered down.
- If the ME does not delete the MBMS keys at power down, then the MBMS keys need to be stored in non-volatile memory.
- The ME should store the MUKs in non-volatile memory in order to be able to authenticate the first MIKEY message of a BM-SC solicited pull procedure
- If the ME deletes the MSK at power down, then the MBMS client would need to request MSK to the BM-SC and may need to run GBA to reconvene an MBMS session.
- GBA_ME = ME-based GBA
- GBA_U = GBA with UICC-based enhancements
- Ks_NAF = Derived key in GBA_ME of
- A UICC that contains MBMS key management functions shall implement GBA_U;
- When a UICC is used, the keys MSK and MUK may be stored within the UICC or the ME depending on the UICC capabilities.
Figure: ME based key management in UE
2). For UICC-based key management:
- When a MSK delivery procedure has to be performed and the corresponding Ks_int_NAF (GBA NAF key) is no longer available in the UICC, the UE shall re-generate a Ks_int_NAF key.
- If the received MSK delivery procedure refers to a Ks_int_NAF key no longer available and if the bootstrapped key Ks is associated to the same B-TID, then the ME should re-generate Ks_int_NAF with a GBA NAF derivation procedure.
- In case that the bootstrapped key Ks has been updated, the ME should take the new B-TID into use and run the MSK request procedure towards the BM-SC which retrieves the latest Ks_int_NAF from the BSF.
- The ME shall control the deletion of MUKs stored on the UICC.
- When the ME wants to free up storage in the UICC for new MUK, the ME selects the MUK no longer needed to be deleted.
- If a MUK is deleted then the corresponding GBA NAF Keys (i.e. GBA NAF Keys with same NAF-ID) shall be deleted; the bootstrapped key Ks shall also be deleted if Ks is present and associated to the same B-TID.
- BSF= Bootstrapping server function
- Ks_ext_NAF = Derived key in GBA_U
- Ks_int_NAF = Derived key in GBA_U, which remains on UICC
Figure: UICC based key management in UE
- An MBMS User Service is composed of one or more MBMS Streaming Sessions and/or MBMS Download Sessions.
- An MBMS Streaming Session is composed of one or more RTP sessions
- An MBMS Download Session is composed of one or more FLUTE channels as defined in TS 26.346.
- MBMS streaming/download sessions may be transported over one or more MBMS Transport Services. Transport Services are defined in TS 22.246.
- MBMS security is used to protect RTP sessions and FLUTE channels.
- As such MBMS User Service protection is Transport Service independent, in particular, it is independent on whether it is carried over point-to-point bearer or MBMS bearer (in multicast mode or in broadcast mode).
1.9. Security – MIKEY message creation and processing in the ME
A). MIKEY Overview
- MIKEY is used to transport the MSKs and MTKs from the BM-SC to the UE.
- MIKEY shall be used with pre-shared keys as described in RFC 3830.
- The pre-shared key used for transmission of MSK is the MUK, and the pre-shared key used for transmission of MTK is the MSK.
- In case MIKEY packets are FEC-protected (see TS 26.346), this is signalled within the MBMS User Service Description.
- As MIKEY is used in a key transport mode, the key derivation function as defined in RFC 3830 shall be used for MIKEY internal keys and MIKEY internal salt.
- To keep track of MSKs and MTKs, a new Extension Payload (EXT) is added to MIKEY.
- The Extension Payload can contain the key types and identities of MSK and the MTK and Key Domain ID
- Some MIKEY payloads contain text strings, e.g., the IDi and IDr payloads. These strings shall be encoded according to UTF-8.
- The size of the authentication key to be used to verify the MAC field of a MIKEY message shall be 160 bits.
- The UDP port number for MIKEY is 2269
- BM-SC is to create the MIKEY messages
- The initial processing is done by the ME received on these MIKEY messages.
- The final processing is done by the MBMS key Generation and Validation Function (MGV-F)
B). MIKEY Common Header (N/A Here)
- MSKs shall be carried in MIKEY messages. The (MSK) messages are sent point-to-point between the BM-SC and each UE. The (MSK) messages use the MUK shared between the BM-SC and the UE as the pre-shared secret in MIKEY.
- Once the MSK is in place in the UE, the UE can make use of the MTK messages sent by the BM-SC over MBMS bearer. The MTK is carried in messages conforming to the structure defined by MIKEY and use the MSK as the pre-shared secret.
- If the BM-SC requires an ACK for an MSK key update message this is indicated by setting the V-bit in the MIKEY common header.
C). Replay protection (N/A Here)
- There is one counter per UE for MSK delivery, and one counter common to all UEs for MTK delivery.
- The counter is used for replay protection; messages with a counter less than or equal to the current counter are discarded. Less than or equal is to be taken in the meaning of RFC1982.
D). General Extension Payload (N/A Here)
- The MSK and MTK shall be delivered in messages that conform to the structure defined in RFC 3830 (MIKEY).
- To be able to keep track of the key that is derived in the message, a general Extension Payload (EXT) is used that conforms to the structure defined in reference.
- The EXT includes a Key Domain ID and one or two Key Type ID sub-payloads depending on the message (see Figure below).
E). MIKEY message structure (N/A Here)
- The structure of the MIKEY message is carrying a MSK key as Figure below. (For handling of unknown MIKEY extension payloads in MGV-F).
F). MSK message structure (N/A Here)
G). MTK message structure (N/A Here)
H). Processing of received MIKEY messages in the ME (N/A Here)
I). Validation and key derivation functions in MGV-F (N/A Here)
1.10. Security – Protection of the transmitted traffic protected
DRM:
- The traffic for a particular MBMS User Service may require some protection depending on the sensitivity of the data being transmitted (e.g. it is possible that the data being transmitted by the MBMS User Service is actually protected by the DRM security method and hence might not require additional protection. However, MBMS protection is independent of DRM protection).
- If this DRM protection is required, it will be either confidentiality and integrity or confidentiality only, or integrity only. The protection is applied end-to-end between the BM-SC and the UEs and will be based on a symmetric key shared between the BM-SC and the UEs that are currently accessing the service.
Ciphering:
- When MBMS data is received over a point-to-point MBMS radio bearer, it would be ciphered between the BM-SC and UE and may also ciphered over the radio interface.
- This
- The data transmitted to the UEs is protected by a symmetric key (an MTK) that is shared by the BM-SC and UEs that are accessing the MBMS User Service.
A). Overview of Data Protection:
- The protection of the data is applied by the BM-SC Session and Transmission Function.
- In order to determine which MTK was used to protect the data key identification information is included with the protected data.
- The key identification information will uniquely identify the MSK and MTK.
- The MTK is processed according to the methods described. Whenever data from an MBMS User Service has been decrypted, if it is to be stored on the UE it will be stored decrypted.
The following traffic protection functions can be distinguished between streaming data and download data:
- Protection of streaming data
- Protection of download data
- The actual method of protection specified may vary depending on the type of data being transmitted, e.g. media streaming application or file download.
B). Protection of streaming data (N/A Here)
1). Usage of SRTP (RFC 3711) (N/A Here)
- When it is required to protect MBMS streaming data via SRTP (Secure Real-time Transport Protocol) as defined in RFC 3711 shall be used.
- The MTK is carried to the UEs from the BM-SC using RFC 3830 (MIKEY) with extensions defined according to this specification.
2). Usage of SRTCP (RFC 3711) (N/A Here)
- Secure RTCP (SRTCP) provides the same security services to RTCP as SRTP does to RTP. As defined in TS 26.346 only RTCP sender reports are allowed in MBMS.
3). Packet processing in the UE (N/A Here)
- Figure: Delivery of protected streaming content to the UE
C). Protection of download data (N/A Here)
- Data that belongs to a download MBMS User Service is decrypted as soon as possible by the UE, if the MSK needed to provide the relevant MTK is already available on the UE.
1). Usage of OMA DRM DCF (DRM Content Format)
1.11. MBMS Procedures (33.246)
MBMS Security related Procedures:
A). MBMS User Authentication and authorisation
- BM-SC shall implement initiation of bootstrapping and bootstrapping renegotiation procedures over Ua (using MRK)
- HTTP based key management procedures between the BM-SC and the UE
- Authentication and authorisation in HTTP digest authentication procedures
The following procedures use HTTP digest authentication: (in 33.246)
- MBMS User Service Registration procedure
- MBMS User Service Deregistration procedure
- MSK request procedure. This can have many triggers
- Associated delivery procedures (specified in TS 26.346).
B). Overview of MBMS Key Management Procedure:
- In order to protect an MBMS User Service, it is necessary to deliver both MSKs and MTKs from the BM-SC to the UE.
- MSK procedures are further divided to MSK request procedures, and MSK delivery procedure. MSK procedures use a point-to-point bearer. MSK procedures are similar for both streaming and download services.
- MBMS key management messages shall use a non-real time PDP context of QoS class
- The BM-SC shall store the IP-address which was assigned for the PDP context for further key management usage.
- The BM-SC receives the IP address of the UE from the source IP address field of the MBMS User Service Registration message.
- It shall be ensured by the network that the original source UE IP address is visible to the BM-SC.
- The operator may configure the BM-SC to refrain from pushing the MSK update message to the UE and let the UE request for the MSK.
- This may be needed in some download services where the UE fetches the MSK after receiving encrypted download object. In this case the back-off mode shall be used if present within the Service Announcement.
- MTK delivery procedures use the same bearer as the MBMS User Service. MTK delivery procedures are different for streaming and download services
C). Procedure of MBMS Key Derivation, Management and Distribution: (33.246)
Procedures of Key Derivation: (MRK)
1. MRK Procedure:
The following function is used by the Key derivation procedures listed below:
- MRK derivation
Procedures involved in Key Management and Distribution: (MSK and MTK)
2. MSK Procedure:
MSK identification
- MBMS User Service Registration procedure;
- MBMS User Service Deregistration procedure)
MSK request procedure
- Basic MSK request procedure;
- Missed key update procedure;
- BM-SC solicited pull procedure
MSK delivery procedure
- Pushing the MSK to the UE
3. MTK Procedure:
MTK Delivery / Update procedure
- MTK delivery in download;
- MTK delivery in streaming)
MSK deletion procedure:
MUK deletion procedure
4. Handling of multiple status codes within one response message
- There is also a status code in the status line of the HTTP response message, which has a successful value if the BM-SC was able to successfully process the corresponding request message. Otherwise the status code in the HTTP status line shall indicate the appropriate error.
- NOTE: This means that there are two levels of status codes in the response message: the status code in the HTTP status line that is specific to the HTTP message and processed by the HTTP application and the one or more status codes in the payload that are specific to and processed by the MBMS application.
- In case the response message does not include all the same status codes in the payload that were in the request message, the UE may still process the status codes that it is able to process.
D). UICC-ME interface Procedure: (33.246 Annex D)
MSK Update Procedure
MTK generation and validation
MSK deletion procedure
- This procedure enables the ME to control the deletion of MSKs stored on the UICC
MUK deletion procedure
- This procedure enables the ME to control the deletion of MUKs stored on the UICC.
E). Procedures in different network element functions:
- Key Request function in BM-SC Key Management Function: The implements the following functions and procedures:
- Bootstrapping initiation
- Bootstrapping re-negotiation
- HTTP digest authentication
- MRK derivation
- MBMS User Service Registration procedure
- MBMS User Service Deregistration procedure
- MSK request procedure
- Key Distribution function in BM-SC Key Management Function: The implements the following security procedures:
- MSK delivery procedure
- MTK delivery procedure
- BM-SC solicited pull procedure
- Session and Transmission function in BM-SC: The implements the following security procedures:
- Protection of streaming data
- Protection of download data
沒有留言:
張貼留言