Confidential. For use within only Slide 1 iOS and Android content protection requirements Version 0.2 Sony Pictures Entertainment Tim Wright

Confidential. For use within only Slide 2 iOS guidelines (1) - applications Use of resident iPad http live streaming player via Safari browser is not ideal because: –No compliance and robustness rules governing implementation security and compliance –No legal framework governing implementers –Complete dependence on Apple for updates to security SPE therefore recommend (but do not mandate) security for iOS devices to be provided by applications implementing a recognised DRM –The resident http live streaming (HLS) player on the iPad can still be used, via secure conversion from the application/DRM to the HLS client on the device

Confidential. For use within only Slide 3 iOS guidelines (2) - applications Applications (if used) should have functionality to detect if –device has been jailbroken –debug tools are installed on the device –other known iPad compromises have been effected Applications (if used) should shut down if any of these compromises are detected

Confidential. For use within only Slide 4 iOS guidelines (3) – use of http live streaming to Safari browser Use of an app requires 30% charge to Apple, so use of http live streaming (HLS) via Safari browser on iOS devices is acceptable All relevant iOS requirements must be met –Key requirements are (but see full list later) Unique https (SSL) URLs for m3u8 file delivery Unique https (SSL) URLs for content encryption key file delivery Content must be encrypted Content must be streamed only with no caching

Confidential. For use within only Slide 5 Android guidelines (1) For Android 2.3 and later, SPE strongly recommend that the DRM be provided using the resident Widevine DRM APIs and not via any other DRM –If Widevine is not used, the application providing the DRM should have in-built countermeasures and security to give the same level of protection as is provided by the resident Widevine DRM –For example, non-Widevine DRM applications should have functionality to detect if debug tools are installed on the device the device has been “rooted” (compromised so that they attacker has Linux root privileges on the device) other known compromises have been effected

Confidential. For use within only Slide 6 Android guidelines (2) If the resident http live streaming (HLS) client is used (resident for Android 3.0), for performance reasons, then Widevine should be used to secure this, and not just rely on HLS security Cryptographic operations, keys within the app, and other sensitive functions and data within the app should be implemented within Android native code (C code) and not in Android Dalvik Java bytecode (which can be easily reverse engineered)

Confidential. For use within only Slide 7 General app security guidelines (both iOS and Android) App provider must be committed to monitoring for attacks on their app and to update the app if required SPE requirements in Content Protection Schedule must be met Software obfuscation must be used to conceal keys and functions within the app Apple App Store and Android Marketplace require the app posted there to be identical for all downloads –No device unique keys can therefore be in the app initially downloaded –The downloaded app must therefore contain an obfuscated key (global) which is used to authenticate the app by content service providers –App should then be individualised with unique keys bound to the device itself before protected content is delivered

Confidential. For use within only Slide 8 http live streaming requirements (1) 1.The URL from which the m3u8 manifest file is requested shall be unique to each requesting client. 2.The m3u8 manifest file shall only be delivered to requesting clients/applications that have been authenticated in some way as being an authorized client/application. 3.The streams shall be encrypted using AES-128 encryption (that is, the METHOD for EXT-X-KEY shall be ‘AES-128’). 4.The content encryption key shall be delivered via SSL (i.e. the URI for EXT-X-KEY, the URL used to request the content encryption key, shall be a https URL). 5.The SSL connection used to obtain the content encryption key shall use both server and client authentication. The client key must be stored securely within the application using obfuscation or a similar method of protection. It is acceptable for the client key used for SSL client authentication to be the same for all instances of the application. 6.Output of the stream from the receiving device shall not be permitted unless this is explicitly allowed elsewhere in the schedule. No APIs that permit stream output shall be used in the application.

Confidential. For use within only Slide 9 http live streaming requirements (2) 7.The client shall NOT cache streamed media for later replay (i.e. EXT-X- ALLOW-CACHE shall be set to ‘NO’). 8.iOS and Android 3.0 applications implementing http live streaming shall use APIs within Safari, Quicktime or Android (as applicable) for display of content to the greatest possible extent. That is, applications shall NOT contain implementations of http live streaming, decryption, de-compression etc but shall use the provisioned iOS/Android APIs to perform these functions. 9.iOS and Android 3.0 applications using http live streaming shall follow all relevant Apple or Android developer best practices and shall by this method or otherwise ensure the applications are as secure and robust as possible. 10.Licensee shall migrate from use of http live streaming (implementations of which are not governed by any compliance and robustness rules nor any legal framework ensuring implementations meet these rules) to use of an industry accepted DRM or secure streaming method which is governed by compliance and robustness rules and an associated legal framework, within a mutually agreed timeframe. The provisioned http live streaming client may be used for performance reasons but delivery of content to the client shall be protected with the industry accepted DRM or secure streaming method