4b／5b编解码对100BASE－TX以太网安全性的影响

杨福宇

（重庆工业自动化仪表研究所，重庆401123）

引 言

以太网已渗透到工业领域，例如工业自动控制中的各种工业以太网（如Profinet、etherCAT、EPA），航空领域的AFDX，汽车领域的 Open（One－pair ether－net），目前主要是基于IT领域的100BASE－TX以太网技术。工业领域与民用有较大的区别：现场的干扰大，实时性要求高，可信赖性要求高。所以它们都添加了许多措施来满足这样的要求。但是对深埋在底层机制中的问题尚未触及，即物理层中的4b／5b编码／解码，它会影响到帧的CRC检验效果。物联网、云计算等介于民用与工业应用之间，它们也倚赖以太网传送数据，所以也要重视这一问题可能带来的影响。

以太网的传送速率比较高，为了传送中不致出现长时间的同一极性的信号电平传送，造成接收处时钟恢复的困难以及直流电平漂移引起信号失真，或者频率域上能量分布不均，某一频率下的成分太高，造成电磁干扰太大，影响周边环境中的电子装置，所以在物理层有专门的编码设计。这些设计会造成传送中产生的误码数目放大，虽然32位CRC检验可以发现部分错，但仍容易造成错帧漏检，对控制用途的工业以太网来说已经超出了容许值。鉴于工业以太网已有规模性的应用，有些还是安全攸关的，这一问题就很严重。

1 4b／5b编码／解码

图1是100BASE－TX收发器的方块图，以太帧的数据以4b为单位经MII接口送到收发器，然后经4b／5b编码器转为5b，串行化后再经扰码器、3电平编码送往输出。扰码器是带反馈的线性移位寄存器，它提供一个频谱较宽的数据流，它的输出与4b／5b编码器的串行输出异或后到3电平编码器。所以它只是提供一个调制信号。真正在电缆上传送的是5b编码且经乱码后的数据流，它的传送速率是125Mb／s。接收过程正好相反，由于扰码器开始在收发二端实行了同步，在线路上不出错的情况下，收到的5b编码就是发送的5b编码。如果线路上有干扰，收发二端的5b编码就有所不同，误码的个数可在5b编码流中统计。但是，以太帧的CRC检验是对解码后的4b数据进行的。CRC检验一般以海明距离（HD）来表示其检错的能力，例如HD＝4表示发生4个位（bit）错时，这时CRC检验可能验不出错，只能保证任意3个位错一定可验出来。根据参考文献［1］，以太网的32位CRC多项式只能达到HD＝4。4b／5b编码如表1所列。

图1 100BASE－TX方块图（见MC9S12NE64单片机）

表1 100BASE－TX以太网4b／5b编码

1.1 误码扩展关系

由表1可见，电缆上以5b编码传送中发生一个错时，在收发两端会产生4b编码的多位错，例如4b码0000对应的5b编码为11110，传送中在5b编码的第5位错变为01110，解码回来是0110，就有2位错，更严重的是传送中在5b编码的第2位错变为11100，解码回来是1110，就有3位错。对每种4b编码的改变情况分析后可知，误码扩展较多为2倍。这种误码的扩展是否线性地缩小了CRC检验的HD是值得关心的，如果扩展2倍，原来的CRC检验理论HD＝4，就只相当于实际HD＝2了。

5b中未被占用的部分或者是非法代码，或者是控制代码，发生变为这类5b错时会有其他的报错措施处理，这里就不讨论了。

1.2 模2加法叠加

在关注误码扩展造成CRC检验的有效性下降时，需要考虑有误码时产生的错码多项式。如果错码多项式是CRC生成多项式的倍数，那么CRC检验就失效了，会产生错帧漏检。但是像以太网帧长很长，受CRC检验的部分达到12 112位，要搜索漏检的最小出错数（即受4b／5b编码影响后的海明距离HD）将有天文数字的工作量，需要大型计算机才能完成。但是我们仍能通过简单的搜索来找出HD的上限，可以证明4b／5b编码对原有CRC检验的检验能力有较大的影响。

这个方法是：选择能因5b中的一个误码使某个4b码变为0000的4b作为种子，然后找出最少量的4b种子在帧的不同位置时进行组合，求出CRC值，如果CRC值中含最少量的非全0的4b，且这个4b也是一个种子，那么这个组合误码时便使CRC检验通过，此时参与组合的4b的数目及CRC中的种子数就最少，就是HD。

为此，先要确定哪些4b是种子。根据表1，4b∈｛1110，1010，1100，0110｝，在5b中的一个误码作用下会变成0000。

而｛1000，0100，0010，0001｝需要5b中的2～4个误码才会变为0000。例如0001的5b编码是01001，它需要5b中的4个误码才会变为11110（对应0000）。但是利用模2加法的叠加原理，它们也能在5b中的一个误码时变为0000。我们在0001上叠加0010，于是4b变为0011，对应的4b是10101，5b中的第1位产生误码，变为10100，译码后变为0010，即叠加上的4b，原来的0001不见了，这个5b中的一个误码等效地使0001变为0000。类似地分析其他各种4b，可以得到4b∈｛1110，1010，1100，0110，1000，0100，0010，0001｝时，在5b中的一个误码作用下会变成0000，这些4b称为种子，用于程序的搜索。其余的4b无法满足种子的要求。

叠加原理在CRC检验中是可行的，假定所有产生误码的种子（不管它是否要叠加一个值），都处在CRC域以外，5b中的多个误码就可以由这些种子的变化，而使帧产生以这些种子构成的错码多项式。我们只要搜索以这些种子构成的错码多项式，就可以确定HD的上限了。

2 4b／5b编码解码对16位CRC检验的影响

为了便于读者理解，先以16位CRC检验加以说明。在利用100BASE－TX以太网传送功能安全要求的应用时，往往添加高层协议，这些协议采用附加的16位CRC检验，例如Safety on etherCAT规定每2字节数据添加1个16位CRC检验和。一般地说，对很短的帧，16位CRC检验可以达到很高的错误检出数［2］，例如G＝0xC86C＝［1100，1000，0110，1100，1］，在135位时可达到 HD＝6，即可以检测出所有5位及以下的位错。

但根据本次搜索，在5b传送过程中有3位错就要漏检了。如图2所示，b35～32＝1110，b11～8＝1000时，CRC＝0000，0000，0000，1110，由于很短，甚至用手工也可以进行验算。它的3个非0000的4b均属于种子4b，只要各有一个传送位错就可以变为0000。由于b11～8＝1000需要添加辅助的数据0010，而变为1010，所以要将上述b35～32＝1110，b11～8＝1010及其CRC全部放到以太帧的数据域中，就左移16位，将有Txd51～48＝1110，Txd27～24＝1010，以及Txd3～0＝1110。添加数据的其余4b可以任选。在这个例子的对应半字节处以5b传送时各发生一个错，接收方就会收到Rxd51～48＝0000，Rxd27～24＝0010，以及 Rxd3～0＝0000，而收发双方的差错就时，Exd51～48＝1110，Exdb27～24＝1000，以及 Exd3～0＝1110。它是b35～32＝1110，b11～8＝1000，时CRC＝0000，0000，0000，1110左移16位的结果，所以它是CRC生成多项式的倍数。这个例子就是错帧漏检了，而实际发生的传送中的位错只有3个，且帧的长度仅52位。与未受4b／5b编码影响时的135位时可达到HD＝6相比，可见性能退化很多。

图2 由于5b中有3个位错而错帧漏检的例子

另一个常用的16位CRC是ANSI－16，其生成多项式是 G＝0xC002＝［1100，0000，0000，0010，1］。当 b3～0＝1100时CRC＝0000，0000，0010，1000。它的3个非0000的4b均属于种子4b。将它左移16位，可见数据只要3字节，就可能出现HD＝3的漏检。

由于只要对应的3个4b处是规定的种子或与种子配合生成的特定数据（例如与1110对应的特定数据为1110，与1000配合0010生成特定数据为1010），帧的其余部分可以任选，所以HD＝3的漏检例子的概率是（2－4）3＝2－12。如果考虑16位CRC检验覆盖的数据帧中其他的漏检数据流实例还有很多，那么HD＝3的漏检的概率会很大，例如ANSI－16的搜索结果中会有136次，此时ANSI－16HD＝3的漏检概率大约为0.033。而0xC86C的HD＝3的漏检概率仅0.001，可见不同的生成多项式受影响的程度还是有区别的。

3 对以太网MAC帧32位CRC的影响

仍然用种子4b在以太网MAC帧的不同位置进行组合，搜索找出HD的上限。

由于以太帧长12 112位，有3 028个4b位置，CRC含8个4b位置，搜索比较费时。得到的结果是HD的上限＝4，这似乎与原来CRC检验的HD＝4一致，但是其出现漏检的概率大为增加了。Koopman［1］的计算结果是接近2－32＝2.3×10－10。按本文搜索到HD＝4的每个实例的漏检率相当于（2－4）4＝2－16。而这样的实例有近100个，如此一来，HD＝4的漏检概率大约为0.001 5，大了许多。

上述计算的近似性质源于搜索方法，由于时间的限制，未能做更多的组合搜索。实际上存在4个4b种子的组合，它们的 CRC和是全0。DATA1：b5587～5584＝1010，b715～712＝0110时，CRC和＝0000，0000，0000，0000，0000，0000，1110，0110。DATA2：b8379～8376＝0100，b1727～1724＝1010时CRC和也是＝0000，0000，0000，0000，0000，0000，1110，0110。当DATA1和DATA2相加时便有全0的CRC和。此时4个4b种子全在数据域。根据CRC检验的做法知道，当生成多项式除尽时，CRC检验和是全0。所以当除法做到生成多项式最后一位是b712时已经除尽，上述4个4b种子的位置以4b为单位左、右移时，CRC检验和仍然是全0。可见这样的漏检帧也是很多的，这样的组合未在搜索方法之中，引起漏检概率的低估。

对以太网MAC帧CRC检验，HD＝4的起始位置是帧长大于2 975位［1］。在本搜索的结果中，由于4b／5b编码的干扰，HD＝4的位置已发现有496位的例子：错误多项式为b495～492＝1000，b395～392＝1110，b19～16＝1000，b3～0＝0001。它的CRC检验和为全0。而在原来未干扰前，这个长度下可以保证HD＝5。

4 4b／5b编码解码影响CRC检验的后果

在分析干扰对误码影响时要考虑这样一点：干扰在时间上不是均匀分布的。误码率是在一段较长时间内统计的平均值，所以在短时间内仍有可能出现较多的误码。干扰发生在电感性负载开关的瞬间，或者雷击的时候，此时误码就较多。功能安全的设计要考虑这个瞬间可能引起的问题。

补充CRC检验是PROFISAFE的关键安全措施，其设计要求是在最坏误码率ber＝10－2时能达到残余错（即错帧漏检 概率）引 起 的功 能 失效 概 率小 于 10－9／h［3］。PROFISAFE对123字节的数据，采用补充的32位CRC，此时码长为984位。假定这个32位CRC与以太网的一样（如果不一样，则需要做相应的搜索，找出4b／5b编码对该CRC检验HD的影响，这是工作量的问题，不妨碍以下讨论），按本文搜索到的例子，只要496位就会发生HD＝4的情况，这个误差多项式在984位中有（984－496）／4＝122个可存在的位置，所以它的安全数据被错帧漏检的概率是（ber）4×122。在ber＝10－2时，错帧漏检概率就是1.22×10－6。对PROFISAFE而言，他们可能原来考虑在984位长度时，32位CRC的 HD＝6，ber＝10－2时，错帧漏检概率就是1×10－12。即便这样，如果每小时送的帧数考虑进去，还是不到要求：在100Mb／s速率下，每个MAC帧长为12 112位，加上先导符，空闲等开销，假定为15 000位，则需0.15ms，每小时可送2.4×107个 MAC帧，再假定总线利用率为20%，则每小时可送4.8×106个 MAC帧，假定每个MAC帧只送1个PROFISAFE帧，则每小时可 送 4.8×106个 PROFISAFE 帧，这 样，由 于PROFISAFE传送错帧引起的安全失效概率将是4.8×10－6／h＞＞10－9／h。如果将ber设为10－3，那么引起的安全失效概率将是4.8×10－12／h，可以达到要求。但是由于4b／5b编码对原有CRC检验的检验能力有大的影响，使ber＝10－2时，错帧漏检概率就是1.22×10－6，引起的安全失效概率将是5.8／h，在ber＝10－3时安全失效概率将是5.8×10－4／h，仍达不到要求。只有当ber＜10－5时，才能达到要求，而这会严重影响其使用：必须加大投资，对干扰严防死守。

对于其他的用法，例如未加功能安全协议的AFDX，参照上述计算，每小时收到漏检错帧的数目非常大，在ber＝10－3时安全失效概率将是5.8×10－4／h。特别是，尽管有双通道的冗余，但是它只收下第一个通过CRC检验的帧，不管是否漏检的帧，冗余不能减弱这种风险。在飞机上，要想从源头上减少电磁干扰更为困难：你难以把雷击的干扰弱化，特别是以后为减轻重量与成本要采用纤维蒙皮。

笔者电子邮件地址：yfy812＠163.com。

［1］Koopman P.32－bit cyclic redundancy codes for Internet applications［OL］.（2012－05－23）［2013－03］.http：／／citeseerx.ist.psu.edu／viewdoc／download doi＝10.1.1.131.2899＆rep＝rep1＆type＝pdf

［2］Philip Koopman，Tridib Chakravarty.Cyclic Redundancy Code（CRC）Polynomial Selection For Embedded Networks ［OL］.（2006－12－22）［2013－03］.http：／／www.ece.cmu.edu／～koopman／roses／dsn04／koopman04＿crc＿poly＿embedded.pdf.

［3］PROFIsafe System Description ［OL］.（2012－11－22）［2013－03］.http：／／www.profibus.com／nc／downloads／downloads／profisafe－technology－and－application－system－description／download／9594.