Home > Communication Service Provider Solutions > Converged Core > Guides > Dell Technologies 5G Core Validated Design with Oracle and VMware Reference Architecture Guide > Security
Because 5G touches every aspect of our lives with its broad set of use cases, the potential security threat is likely to increase. Operators must invest heavily to secure their 5G networks before they can consider use cases supporting business-critical and mission-critical industry-vertical applications such as healthcare and banking.
In the 5G SBA, all NFs can communicate with each other through an API that is based on HTTP and JSON. This communication capability requires a careful design to protect the data in the network (to avoid eavesdropping of the traffic) or to authorize communications among NFs (to avoid that a malicious actor registers a fake producer NF to the NRF and starts receiving traffic from other consumer NFs).
The solution supports standard security mechanisms that are defined by 3GPP:
NRF supports 3GPP 29.510-based verification for access-token authorization requests for specific NF producers based on the allowed NF type and PLMN that are present in the NF profiles. An extension to this requirement is to include screening for access-token requests based on the NF type.
NRF performs the required authorization, and, if successful, will issue the token with the requested claims. The NRF provides an option to the user to tailor the authorization of the producer-consumer NF types along with the producer NF's services. The operator configures the mapping of the requester NF type, target NF type, and allowed services of the target NF. An access-token request is received based on the configuration and is further processed only if the authorization is successful. Allowed services can be configured as a single wildcard ('*'), which denotes that all the target NFs services are allowed for the consumer NF. The operator can also configure the HTTP status code and error description to be used in the error response that is sent by the NRF when the access token request is rejected.
Private keys are used by NRF to sign the access token that is generated. The private key is available only in the NRF. Public certificates are used by producer NFs to validate the access token that is generated by NRF. Accordingly, public certificates are available with producer NFs. NRF does not need the public certificate while signing the access token. The expiry time of the certificate is required to set appropriate validity time in the AccessTokenClaim.
Private keys are used by NRF to sign the access token that is generated. The private key is available only in the NRF.
Public certificates are used by producer NFs to validate the access token that the NRF generates. Accordingly, public certificates are available with producer NFs. NRF does not need the public certificate while signing the access token. The expiry time of the certificate is required to set an appropriate validity time in the AccessTokenClaim.
Two types of signing algorithms are supported by the NRF:
HTTPS, an extension of HTTP, can be used to establish a secure connection between NFs in a 5G network, as defined in 3GPP TS 33.501. The HTTPS protocol uses Transport Layer Security (TLS) to encrypt the communication protocols between NFs, providing confidentiality and integrity protection to 5G Service Based Interface (SBI) messages.
To enable HTTPS on SBI messages, two NFs start the TLS handshake to agree an algorithm and keys to send messages securely to each other. After the handshake is completed, all communications between the client and the server are encrypted. This includes the full URL, data (plain text or binary), cookies, and other headers. The domain or host to which the client requested a connection is not encrypted because, when the connection is initiated, an HTTP request is made to the target server to create the secure connection. When HTTPS is established, the full URL is used.
This initialization must occur only once for each unique connection. In this respect, HTTP/2 has a distinct advantage over HTTP/1.1 because it multiplexes connections instead of opening multiple connections.
In indirect communications, the consumer and producer NFs communicate through the SCP, which accepts secured ingress connection requests from a consumer NF and establishes a secured egress connection with a producer NF.
Both HTTPS/TLS and Access Token/O Auth require a way to manage the keys and certificates that are required on all NFs. This is managed by a manual procedure in which each NF generates the private/public keys and can generate a Certificate Signature Request (CSR) to a Certificate Authority (CA). The CA can provide certificates to be installed on the database.