关于AES加解密中CBC模式的IV初始化向量的安全性问题

前段时间，在研究HLS的AES加密，由于一个地方电视台的HLS流有AES加密，在查看了相关的加解密方案后发现使用的是简单的AES的CBC模式，在CBC的模式下，会设置一个IV，初始化向量。但是我在解密的时候，使用了一个由于理解错误而产生的一个错误IV居然也能解密视频并进行播放，于是就有了这篇张文章。

AES五种加密模式（CBC、ECB、CTR、OCF、CFB）

虽然有五种加密，但是常用的还是CBC，CBC的全称Cipher Block Chaining ，有点类似于区块链哈，我们先来看下加密方式

CBC加密

上面的图片从左往右看，初始化IV只有在第一个块加密的时候才会用到，而第N个块的加密IV则是用的N-1(N>1)个加密后的二进制数组。

CBC解密

CBC的解密则也是从左往右看，但是加密时IV在解密时候，只会用于对第一个块进行解密，其他块的解密则是使用上一块的加密二进制作为IV进行解密操作。

加密时，用iv和key去加密第一个块，然后用第一个块的加密数据作为下一个块的iv，依次迭代。解密时，用n-1个块的加密数据作为iv和key去解密第n个块（n>1），只有第一个块才会用加密时的iv去解密第一个块。按照这样的逻辑来看，那么如果解密时，使用了iv错误，出问题的数据应该只有第一个块。

通过上面的分析就能知道，加密的时候，iv会影响所有数据的加密结果，而解密时，iv只会影响第一个加密块的解密结果，其他块的解密可以直接通过分隔加密数据获取正确是N-1块的IV。

这也就印证了为什么ff能播放我用错误的iv解密出来的视频流数据，因为第一块的大小存储大概是id3 的数据，ff直接丢掉id3的数据，直接解码后面的视频数据 ，ff 应该是识别h264编码头开始解码视频。

那么从这点可以看出，在使用了key的情况下，IV对整个数据的保密性没有太大的作用。

再来说说我是怎么发现这个问题，因为错误的IV只会影响第一个块的数据，我在第一次尝试解密后，直接用ff进行播放，ff能够解码并且播放成功，但是相对于其他未加密的HLS流来说，播放我解密后的数据会有3-5s的延时，这让我很是头疼，后来我就通过ffplay -v trace 打印播放解密的日志，发现视频数据的id3信息丢失了，那么出问题出在第一个块。然后再次研究m3u8加解密IV的赋值方法，后发来经过多次试验，正确赋值IV，解密出来的数据能够及时播放。再后来，就出现了这篇文章的来由。

由此带来的延展，针对iv在CBC模式下的弱用，AES提供了更多的模式可供选择，详细的可以到wiki上了解。

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

From: https://www.jianshu.com/p/45848dd484a9

Transparent proxy with nftables

This is an example of configuring transparent proxy(tproxy) with nftables. The tproxy application is hev-socks5-tproxy

Netfilter rules

DON’T FORGOT TO ADD UPSTREAM ADDRESS TO BYPASS IPSET!!
Or use nftables skuid/skgid match to exclude proxy process.

table inet mangle {
    set byp4 {
        typeof ip daddr
        flags interval
        elements = { 0.0.0.0/8, 10.0.0.0/8,
                 127.0.0.0/8, 169.254.0.0/16,
                 172.16.0.0/12, 192.0.0.0/24,
                 192.0.2.0/24, 192.88.99.0/24,
                 192.168.0.0/16, 198.18.0.0/15,
                 198.51.100.0/24, 203.0.113.0/24,
                 224.0.0.0/4, 240.0.0.0-255.255.255.255 }
    }

    set byp6 {
        typeof ip6 daddr
        flags interval
        elements = { ::,
                 ::1,
                 ::ffff:0:0:0/96,
                 64:ff9b::/96,
                 100::/64,
                 2001::/32,
                 2001:20::/28,
                 2001:db8::/32,
                 2002::/16,
                 fc00::/7,
                 fe80::/10,
                 ff00::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff }
    }

    chain prerouting {
        type filter hook prerouting priority mangle; policy accept;
        ip daddr @byp4 return
        ip6 daddr @byp6 return
        tcp dport { 0-65535 } tproxy to :1088 meta mark set 0x00000440 accept
        udp dport { 0-65535 } tproxy to :1088 meta mark set 0x00000440 accept
    }

    # Only for local mode
    chain output {
        type route hook output priority mangle; policy accept;
        ip daddr @byp4 return
        ip6 daddr @byp6 return
        tcp dport { 0-65535 } meta mark set 0x00000440
        udp dport { 0-65535 } meta mark set 0x00000440
    }
}

Routing rules

ip rule add fwmark 1088 table 100
ip route add local default dev lo table 100
 
ip -6 rule add fwmark 1088 table 100
ip -6 route add local default dev lo table 100

See also: https://github.com/heiher/hev-socks5-tproxy/blob/master/README.md

The nftables config file that bypass all IPv4 and IPv6 sets of China: https://gist.githubusercontent.com/heiher/fd001c69eda8d1f87bb66c3f44509c11/raw/nftables.conf