RIST Pre-Shared Key Encryption

RIST Pre-Shared Key Encryption

November 22, 2019

Video: RIST Pre-Shared Key Encryption - RIST is all about the combination of interoperability and innovation that provides an open, interope

RIST can protect content in a manner that probably makes the most sense for live streamers who wish to keep the maximum amount of revenue at the lowest cost of distribution. For those providers with a very large audience, it might not be the answer, because they might be able to get a better deal from an aggregator. Its easy implementation and superior viewing quality are sure to make encrypted RIST streams a popular addition to streamers' toolboxes.

Though some might say that the combination of media encryption and an open source standard such as RIST is a contradiction in terms, quite the opposite is the case. Any creator producing their own content invests their time and money in production and distribution. If they can produce with low cost tools, monetize without paying "toll road" providers such as YouTube, and distribute with a high quality viewing experience using a standard like RIST without having to pay additional to a mega-CDN, it's a win-win. The creator protects their intellectual property, keeps a bigger share of the monetization, and the viewer gets a better quality viewing experience due to RIST's error correction protocol. RIST can be another tool in the toolbox for those that want to keep a media workflow under their own control. It's particularly an important tool for live streamers, where the content's value may decrease with time, and the delay in curating and uploading a stream could lead to a big difference in revenue.


RIST provides two types of encryption options in the Main Profile protocol spec, both of which support either AES-128 or AES-256. So, the hardiness of both is a given. They both utilize a tunnel, so that RIST can be implemented with just one port instead of two. They are much more firewall-friendly than "regular" simple profile RIST, because it's flexible about which side the tunnel starts. That makes it much easier to use when the viewer's IP address is NAT'ed through the home gateway. The tunnel, by the way, can carry multiple streams.
The first option uses the DTLS (Datagram Transport Layer Security) protocol. It's similar to https protection in that it is certificate based. It supports self-generated or certificate-authority issued certs. The client isn't required to have a certificate, but if the content creator so wishes, that can add to the security of the connection.
The second option is the Pre-Shared Key (PSK) encryption protocol. But whereas the DTLS encryption over RIST protocol is meant for point-to-point, or one-to-one connections, PSK additionally enables one-to-many connections. Using PSK on this basis, a small creator can pre-distribute a key to viewers, then stream directly to all. Subsequent Key/Initial Vector changes ensure that access control doesn't get stale.


In this PSK scenario, the payload of the GRE Packet, excluding the GRE header, is encrypted using an AES key derived from the key field plus the pre-shared passphrase. So if the content provider has a secure means of distributing their passphrase, they're assured of a high level of security for their content. The sender also sets the S (sequence number) Field, which will be used as the initial vector. The nonce must be regenerated by the sender at least every time the sequence counter wraps to zero; or, they can do it more frequently. The receiving end has to examine the nonce with each packet received and regenerate the key whenever it changes.
While it takes a little more work than DTLS to implement, PSK can also provide flexibility to resolve other problems besides multiple receivers. For example, whereas DTLS' certificate verification might not be feasible on some devices without a real time clock (such as Raspberry Pi based equipment), PSK will work just fine. PSK encryption can also support Forward Error Correction for the RIST stream. In a "one to many" distribution environment, the investment in overhead for the forward error correction might eliminate many resend requests, resulting in an overall lower total amount of outbound traffic from the sender in a one-to-many environment. 
We should note also that PSK, on a one sender/one receiver basis, can support multipath or bonding. This means it supports higher speeds and redundant providers. This makes it even more suitable as a distribution mechanism between remote site and headquarters.