Skip to content

Security

The Peer5 service is just as secure as any traditional server-based CDN service. Because Peer5 is a hybrid solution - one uses Peer5 in combination with a traditional HTTP server - we leverage the existing security infrastructure (tokens, keys, cookies, etc) that a customer already has in place.

In terms of communication, peers are connected to each other via the WebRTC data channel which is a secure pipe that uses the SCTP protocol over DTLS encryption. Additionally, each viewer is connected to the Peer5 backend via a secure Websocket connection that uses TLS encryption. So neither the data sent between viewers nor the metadata sent between each viewer and the Peer5 backend can be compromised.

In terms of stream security, there are several scenarios:

Authentication on session start

In this case, every session begins with the server asking the viewer for a user ID and password. If these credentials are valid, the server will send the manifest file to the viewer and the video player will start requesting segments and additional manifests from the HTTP server accordingly. Peer5 does not insert itself into the validation process and the viewer must pass through the same authentication gates whether or not Peer5 is deployed. Only viewers who are authorized for a stream can participate in P2P sharing for that stream and they only share while they are actually watching the stream.

URI timed tokenization

In this case, the manifest URL has an additional token which encodes a few details about the viewer’s user agent (IP address, expiration time, etc). A malicious user can distribute the manifest URL to unauthorized viewers, but those viewers won’t be able to access the stream since the manifest URL is tokenized and the HTTP server will reject any validation attempts - either because of IP address or other user agent mis-matches or because of time expiration. With Peer5, all manifests requests are sent directly to the HTTP server so validation cannot be compromised.

Encryption

Let’s take for example an HLS stream that is protected with AES-128 encryption. Malicious users can send the manifest URL to unauthorized viewers, or even the video segments themselves, but as long as the unauthorized viewers don’t have access to the decryption key, they won’t be able to watch the stream. The key can be sent to the end user in numerous ways - e.g., via the main manifest, or with the HTML page, or even another path. Regardless, Peer5 does not insert itself into this process, and the key is delivered to the video player using the same mechanism whether or not Peer5 is deployed, which means the key is just as secure with or without Peer5.

DRM

The DRM use-case resembles the encryption use-case - the only difference is that the license and keys are distributed by the DRM mechanism instead of by the broadcaster. Here as well, Peer5 doesn’t interfere with the distribution of the license or keys and thus doesn’t compromise them.