BBC Research and Development’s Simon Rankine will present an update from AMWA’s NMOS API Interoperable Security Group. The group is working to apply tried and tested web technologies to the APIs in order to provide APIs that are simultaneously secure and cross-vendor interoperable.
File Type:
pdf
Categories:
Security
Presenters :
Simon Rankine - BBC
Year :
2019
dlp_document_download :
C U R A T E D B Y I P S H O W C A S E T H E AT E R AT N A B – A P R I L 8 -11 , 2 01 9 AMWA NMOS API Security Simon Rankine – Project Research Engineer BBC Research and Development Motivation • To get the most out of the NMOS APIs we need to be able to run them on networks which we cannot fully control • In particularly sensitive environments it may not be enough to isolate the broadcast network • Attacks on broadcasters such as TV5MONDE highlight that the broadcast industry is a high profile target. • Security protects against accidental as well as deliberate misuse 2 AMWA NMOS APIs and Security • Part of the motivation for using HTTP is that we can harness carefully scrutinised and well developed technology from the web industry. • As such have always been "securable" using standard mechanisms, but to do so would have broken interoperability. • The AMWA set up the API security workgroup to investigate how the APIs could be secured in an interoperable way. 3 Objectives Confidentiality Data passing between client and the APIs is unreadable to third parties. Identification The client can check whether the API it is interacting with is owned by a trusted party. Integrity It must be clear if data travelling to or from the API been tampered with. Authentication The client can check if packets actually came from the API it is interacting with, and vice versa. Authorisation The API can determine whether the client interacting with it has authorisation to carry out the operation requested. 4 Work Areas Connection Security ‒ HTTP over TLS (HTTPS) ‒ Identify cipher suites for interoperability ‒ Establish best practice for use of TLS with AMWA NMOS APIs Establishing Trust ‒ Public key infrastructure with x509 certificates ‒ Explore how PKI can be used in a broadcast environment Client Authorisation ‒ OAuth 2.0 with JSON Web Tokens ‒ Identify what is needed to ensure interoperability Scope 6 Application Transport Network Physical API Client Authorisation (Web Tokens) Session Security (TLS) Site/Server room access etc. Network access control Riedel will cover this at 10:00 -> Connection Security • Tunnels insecure traffic like HTTP through an encrypted connection so that it cannot be read or modified during transit. • The TLS protocol is widely used for securing a wide range of traffic across the internet and on private/corporate networks. • This is achieved using a collection of different algorithms, which together form the "cipher suite". 7 TLS Handshake Cipher Suites TLS _ ECDHE _ RSA _WITH_ AES_256 _ GCM _ SHA384 Protocol Key exchange cipher Key authentication algorithm Block cipher Block cipher mode Hashing Algorithm HTTP over TLS (HTTPS) – Cipher Suites TLS ECDHE ECDSA WITH AES 128 GCM SHA256 TLS ECDHE ECDSA WITH AES 256 GCM SHA384 TLS ECDHE ECDSA WITH AES 128 CBC SHA256 TLS ECDHE ECDSA WITH AES 256 CBC SHA384 TLS ECDHE RSA WITH AES 128 GCM SHA256 TLS ECDHE RSA WITH AES 256 GCM SHA384 TLS DHE RSA WITH AES 128 GCM SHA256 TLS DHE RSA WITH AES 256 GCM SHA384 TLS ECDHE RSA WITH AES 128 CBC SHA256 TLS ECDHE RSA WITH AES 256 CBC SHA384 TLS DHE RSA WITH AES 128 CBC SHA256 TLS DHE RSA WITH AES 256 CBC SHA256 TLS ECDHE ECDSA WITH AES 128 CCM 8 But isn’t this SSL? SSL SSL 1.0, 2.0, 3.0 all insecure – don’t use them! TLS 1.0 No longer considered secure, avoid use. TLS 1.1 Still considered secure, but generally TLS 1.2 is preferred as there is little difference. TLS 1.2 Current best practice – use wherever possible. TLS 1.3 Very recently published as RFC , still finding its way into implementations. Establishing Trust • API servers need to hold a certificate trusted by the client. This certificate must match its subject name (e.g. URL). • Certificates are issued by a trusted 3 rd party – the "Certificate Authority". • Asymmetric encryption is used to allow the certificate authority to "sign" the server’s certificate such that the client can check its authenticity using the public key of the certificate authority. 12 Web Server Root CA Private Key Root CA Certificate CA Public Key Signs Client Issued by browser/OS Server Certificate Public Key www.example.com Issues and signs Server private key TLS Connection 15 16 AMWA BCP -003 -01: Securing communications in NMOS APIs https://github.com/AMWA -TV/nmos -api -security/blob/v1.0 -dev/best -practice -secure -comms.md C U R A T E D B Y I P S H O W C A S E T H E AT E R AT N A B – A P R I L 8 -11 , 2 01 9 Thank You Simon Rankine, BBC Research and Development Simon.Rankine@bbc.co.uk @RankineSimon https:// www.bbc.co.uk/rd/publications/whitepaper337 https:// www.bbc.co.uk/rd/publications/whitepaper338
Downloads:
12