白话说CC之---消除你对EAL5+半形式化的恐惧

小黑：小白小白，我学习了之前的白话说CC的《稍有点小复杂的CC介绍》、《五分钟带你了解EAL4+与EAL5+的区别》和《揭秘穿透性测试》，对CC有了初步的了解。但是到了EAL5+，发现一个抽象可怕的词，就是半形式化，比如“附加错误信息的完备的半形式化功能规范”，“半形式化模块设计”。到底什么是半形式化？你给解释解释。

 

小白：没问题。半形式化是到了EAL5级提出来的概念，可以说不理解半形式化，就不足以谈EAL5+。先给你说说相关概念，注意听讲哈。

说到半形式化，有个半字，自然会想到它是夹在非形式化和形式化之间的一个名词。其实无论非形式化、半形式化还是形式化都是指一种描述方式。就类似管妈妈口头上叫妈妈，书面语叫母亲一样，描述对象都是一个，描述方式不一样而已。

非形式化描述就是用自然语言描述，特点是通俗易懂，缺点是一千个读者心中有一千个哈利波特,可能会有歧义，这在安全评估中是很危险的。

形式化描述，可以简单理解成用公认的数学符号以建模方式进行描述。因为使用了可丁可卯的数学系统，描述出来的内容也是确定的，肯定不会有歧义，这种表述方式也是最严谨的。但是缺点也很明显，就是太复杂，数学渣伤不起。

半形式化夹在两者中间，采用确定的语义和严格语法描述整个文档，通过这种规范化的方式尽可能减少语义歧义。优点是显而易见的，既能保证读者接收到的信息是一样的，又能使编写者好操作。你说半形式化是不是一个不错的表达方式？

 

小黑：听起来是不错。我大概明白了，非形式化、半形式化、形式化通过增加语言的受限程度来减少语义歧义。不过，没图没真相，理解不透啊，举个栗子呗？

 

小白：好。那我用俩图举栗子，说明确定的语义和使用严格语法如何消除歧义吧。先说说明确的语义的重要性吧。如果没有预先说明，读者要判断ECC到底什么含义就要结合上下文了。但如果统一明确了ECC的含义，那么读者根本无需再做判断。是不是这样就轻而易举的统一了读者心目中的哈利波特呢。

 

然后我们再来说说严格语法的好处吧。比如芯片设计包含软硬件，设计文档编写一般不会是由一个人完成的。如果不统一编写风格，很可能因不同作者风格导致信息的遗漏，甚至引入脆弱点。对于读者来说，一份文档多种风格带来的语义歧义更是层出不穷。因此无论对编者来说还是读者来说，规范化的表达都会使文档更加整洁，逻辑更加清晰。

小黑：嗯，有图有真相了。半形式化规范了语言和书写结构，不但使表述更准确，也使文档结构更加合理，逻辑更加清楚明白。那为什么EAL5+要求用半形式化呢？

 

小白：CC定义的EAL1~EAL7级别随着评估程度的深入而提高等级，评估者对TOE理解的准确程度是评估的基础。因此随着评估程度的加深，不同保障级要求开发者提供信息的准确程度也不同。

EAL5+属于高保障级别，需要开发者在EAL4+基础上提供更多、更清晰的自证信息，使评估者能更快更清楚的把握产品功能，从而有助于发现和判断脆弱点。

使用半形式化的描述方式，一方面可以帮助开发者梳理结构，使其提供的信息更严谨，避免遗漏。评估方面，半形式化的方式增强阅读者理解，避免产生歧义，有助于快速掌握安全功能的每个细节，从而判断产品是否存在隐藏的脆弱点。

 

小黑：既然半形式化需要结构化写作，那么CC有没有规定怎么做到半形式化？

 

小白：简单说， CC认为半形式化的目的在于为阅读者消除歧义，因此只要有助于达成这个目的，就可以当做半形式化的方法。规定咋做不符合CC的身份，CC想要的能够评估所有的产品，说的细了肯定做不到。

我们从CC和CEM两个标准来看半形式化的要求。

其实国内也有人研究咋做半形式化。比如石博士写了一篇论文，建议将ASN.1和UML这两种语言用作半形式化描述方法。你要感兴趣，可以拜读一下。

 

小黑：说到现在我大概懂了，半形式化的目的是消除歧义，只要开发者以一种约定好的方法，并保持同一方法描述，使评估者阅读起来没有歧义就可以了,并没有规定开发者必须按照某种特定的方法编写文档。

 

小白：完全正确，正可谓是不忘初心，方得始终。半形式化的问题上千万不要买椟还珠，太机械化的要求这个要求那个，那就违背了半形式化的初衷了。

 

小黑：这么一说，半形式化就是一种表达方式，没那么神秘，也没那么可怕。我要回去再看下标准，不懂再来问。

 

小白：OK！