安全控制方法及计算机系统与流程

文档序号:17490667发布日期:2019-04-23 20:27阅读:249来源:国知局
安全控制方法及计算机系统与流程

本申请涉及计算机系统的安全控制技术,尤其涉及通过审计控制流等信息实现系统安全的方法、设备及系统。



背景技术:

终端设备处理重要服务的需求日益增加。从能够支付、下载和观看某一特定时段的最新好莱坞大片,到能够通过手机远程支付账单和管理银行账户,这些发展趋势已使终端设备成为恶意软件、木马和rootkit等病毒的重点攻击目标。为了保证终端设备的安全性,出现了以trustzone为代表的终端设备安全框架。

在现有的trustzone框架下,系统级的安全是通过将片上系统(systemonchips,soc)的软硬件资源划分到两个世界中分别获得,即正常世界(normalworld)和安全世界(secureworld)(也可以叫安全域和非安全域),这两个世界分别对应富执行环境(richexecutionenvironment,ree)和可信执行环境(trustedexecutionenvironment,tee)。tee和ree运行于同一个设备上,tee能够保证在可信的环境中进行敏感数据的存储、处理和保护,并为授权的可信应用(trustedapplication,ta)提供安全的执行环境。客户应用(clientapplication,ca)(也称之为普通应用)运行于ree上,ca通过调用位于ree的tee客户端应用编程接口(applicationprogramminginterface,api)去访问ta,从而使用tee及ta提供的安全功能。

现有技术中,为了保证ca访问ta的安全性,在ree侧设置有ca的鉴权程序,该鉴权程序用于提取ca的身份信息,以便于后续验证ca的身份。具体的,在ca访问ta之前,ree侧通过执行该鉴权程序提取ca的身份信息,然后通过安全模式调用(securemonitorcall,smc)提交给tee侧,tee侧验证通过之后才允许ca访问它想要访问的ta。但是在ree侧,ca所运行的操作系统(operatingsystem,os)有可能被攻破,导致该鉴权程序被绕过,亦即不执行。例如,以为代表的ree侧的os之上部署有各种ca,而中部署有ca鉴权程序,存在一个超级用户权限,即root权限。当被超级提权(即被root)之后,原有的权限管理不再有效。也就是说,被root之后的ca就有可能在某些攻击情况下绕过鉴权程序。如果鉴权程序被绕过,ca的身份信息提取过程没有了。这样,仿冒的ca就可以将伪造的身份信息直接提交给tee侧,待tee侧验证通过之后,仿冒的ca就可以调用ta提供的安全功能,比如指纹验证功能,进而造成一系列的系统安全问题。



技术实现要素:

本申请提供一种计算机系统、终端设备以及应用在其上的安全控制方法等,用于提高终端设备或其他类型的计算机系统的安全性。

为了方便理解本申请提出的技术方案,首先在此介绍本申请描述中会引入的几个要素。

域:计算机系统的一个逻辑组织单元,具体可以是一台计算机设备内部的逻辑组织单元。每个域都有自己的安全策略,不同域之间存在安全边界。计算机系统的域可能是通过软件划分的,例如系统的用户态和内核态,再例如利用虚拟化技术形成的宿主层(host)和客户层(guest);也可能是通过硬件方式划分的,例如基于trustzone的安全域和非安全域。

跟踪器:本申请中也叫tracer,用于记录cpu上发出的转移指令(例如跳转指令)和数据传输指令(例如中的load指令和store指令)等,这些指令可以作为控制流信息用来重构控制流以及用于获取动态数据等。例如架构下的coresight,x86架构下的ipt(processortracer),或其它可以实现cpu指令跟踪的单元或模块。跟踪器可以独立作为一个装置存在,也可以部分或全部嵌入到cpu中或其他硬件中。

控制流(也可以叫执行流):表示程序的执行过程。控制流可直接或间接地表现为指令地址序列或事件序列。例如代码x=y,转换为汇编语言就是0x1234:loadr0,[y];0x1238:storer0,[x]。这里内存中存着的y的值流动到cpu的寄存器,再流动到x的内存中,该代码的控制流就是先执行0x1234,再执行0x1238,而其中y的值属于代码执行过程中的动态数据。

控制流信息:用来表示可以重构控制流的信息。在一些描述中指形成一段程序的控制流的多条控制流信息中的一条,在另一描述中指形成一段程序的控制流的所有信息,在其他一些描述中也可以用来指控制流本身,具体可参考描述上下文。

数据流:表示程序的数据读写过程,包含过程中的数据。可直接或间接地表现为程序的数据读写事件序列。本申请的一些实施例中通过对读写事件序列中包含的数据进行审计以保证系统的安全性,该数据一般为动态数据。

数据流信息:用来表示可以重构数据流的信息,其中包含动态数据。在一些描述中指形成一段程序的数据流的多个动态数据中的一个,在另一描述中指形成一段程序的数据流的所有动态数据,在其他一些描述中也可以用来指数据流本身,具体可参考描述上下文。

自动机:计算机实现的数学模型。自动机可以响应于外部输入(例如一个事件)而从一个状态转换为另一个状态。自动机实例是一个运行时自动机。在本申请提供的实施例中,规则或模型用来审计控制流等信息,自动机则为“规则或模型”的一种实现形式。

“在第一域或第二域中执行某个动作”可以理解为执行该动作的主体部署在第一域或第二域中,或者可以理解为执行该动作的执行主体处在第一域或第二域所代表的状态,执行动作的主体可以是硬件模块也可以是软件模块;或者由于“域”是逻辑组织单元,所以某些情况下也可以理解为动作的执行主体为第一域或第二域。

本申请中出现的“多个”或“多次”若无特殊说明则意指“两个或两个以上”,或“两次或两次以上”。本申请中出现的“第一”和“第二”并无限定顺序的意思,仅是为了在某些描述上下文中区分两个主体,以方便理解,但是其所指示的主体并非在所有实施例中都必须是不同的主体。本申请中出现的“a/b”、“a和/或b”包括a、b以及a和b三种情况。本申请中意指a为一个商标名称,但没有带的词语也有可能是商标名称。

接下来将分不同的方面介绍本申请提供的技术方案。应理解的是,以下方面未必涵盖本申请提出的所有实现方式,并且不同方面的实现方式和有益效果可互相参考。

第一方面,本申请提供一种计算机系统,具体可以为终端设备,所述终端设备上部署有第一域和第二域,所述第一域内部署有程序,所述第二域内部署有控制流管理模块和审计模块。该终端设备上还部署有跟踪器,与所述控制流模块和审计模块一起实现对所述程序的控制流的完整性审计。具体的,所述控制流管理模块被配置为在位于所述第一域中的程序执行时,通过硬件跟踪器获取待审计信息,所述待审计信息包括所述程序的控制流信息;所述审计模块被配置为根据审计规则对所述待审计信息执行审计,当所述待审计信息匹配所述审计规则时确定审计通过。负责审计的域的安全性通常高于(或等于)被审计的程序所运行的域。第一域和第二域可以是通过软件和/或硬件划分的。

在一些实现方式下,所述第一域和第二域分别为基于trustzone的非安全世界和安全世界(也可以理解为是ree和tee)。

可见,利用跟踪器,例如coresight或ipt,获取关键的程序(下述具体实施方式中称为待保护程序)的控制流信息,并在另一域中根据预设的审计规则对所述程序的控制流进行完整性审计,当所述控制流匹配所述审计规则时才允许下一个操作,例如允许所述程序或与所述程序相关的其他程序访问审计模块所在域的功能等,从而避免由于某种攻击手段导致该关键的程序被绕过执行或非法执行进而引起的系统漏洞,提升终端设备的安全性。

需要说明的是,控制流完整性审计也可以称之为控制流完整性验证,在本申请中简称为控制流审计。

在一些实现方式下,所述程序可以存储在部署在第一域的存储器的只读存储区,避免被修改,进一步保证安全性。

在一些实现方式中,所述待审计信息还包括所述程序的数据流信息。在执行控制流审计的同时也审计程序的数据流信息,代码执行过程的安全性得到保证的同时,代码中的数据的安全性也得到了保证,进一步提高了终端设备的安全性。

在一些实现方式中,该终端设备还包括部署在所述第二域内的tracer审核模块。该tracer审核模块被配置为在所述审计模块执行审计之前对所述跟踪器执行审核。具体的,审核跟踪器的寄存器是否被修改过,若被修改过,则审核不通过,反之,审核通过。审核通过后再触发所述审计模块执行所述审计。在跟踪器做安全审计之前先审核跟踪器,确保跟踪器没有被篡改,保证审计过程的可靠性。

在一些实现方式中,该终端设备还包括部署在所述第一域内的进程标识获取模块。该进程标识获取模块被配置为在所述跟踪器采集所述控制流信息之前获取执行所述程序的进程的进程标识(例如pid或进程名字),并将所述进程标识存入所述跟踪器的第一寄存器中。所述控制流管理模块具体被配置为通过所述跟踪器获取所述待审计信息,所述待审计信息还包括所述进程标识,其中,所述进程标识为所述跟踪器从所述第一寄存器中读取的进程标识。所述审计模块具体被配置为根据所述进程标识查找与所述进程标识匹配的审计规则,并根据查找到的审计规则对所述控制流信息执行审计。

触发采集每条控制流信息之前,先获取当前进程的进程标识,然后再触发采集当前进程执行的程序的控制流信息,之后将该条控制流信息和该进程标识关联存储。相当于每条控制流信息都有一个进程标识标识自己的来源,这样审计模块就可以根据进程标识区分来自不同程序的控制流信息,并选择与之匹配的审计规则进行审计,从而实现多个程序的并行审计。

在一些实现方式中,所述终端设备还包括部署在所述第一域的第一随机数发生器和自采集模块,所述第二域中包含所述程序的text段。这里的text段可以通过硬编码方式置入所述第二域。所述自采集模块被配置为在所述程序被执行之前调用所述第一随机数发生器以产生随机数rx,并将所述随机数rx存入所述跟踪器的第二寄存器;根据所述随机数rx和执行所述程序的进程的text段计算得到哈希值h1。所述控制流管理模块具体被配置为通过所述跟踪器获取所述待审计信息,这里的待审计信息中还包括所述随机数rx,其中所述rx由所述跟踪器访问所述第二寄存器获得。所述审计模块具体被配置为获取所述哈希值h1,根据所述随机数rx和所述第二域中包含的所述text段计算得到哈希值h2,比较所述h1和h2,当所述h1和h2相同且其他待审计信息匹配所述审计规则时确定审计通过。

在另一些实现方式中,可以采用除随机数之外的其他形式对所述text段进行加扰。

在另一些实现方式中,随机数rx也可以不产生,不计算哈希值h1,只传输text段,然后和第二域中包含的text段比较。

“text段”指向一段存储区域。一个程序的text段中包含该程序的代码和常量。权要中的“text段”指text段包含的所有或部分内容、压缩过的text段的内容或text段包含的内容的摘要。

应理解的是,“text”这个名字通常在中使用,在其他系统中,包含程序代码和常量的存储区域可能叫其它名字。应理解的是,在本申请中,“text”段意指所有类型的系统中具备同等含义的存储区域。

text段中包含程序的代码和常量,将text段的内容先置入第二域,然后在程序运行的过程中再获取一次text段,并传输到第二域,两次获取的text段做比较,通过后才确定审计通过,这样可进一步确保程序的安全性。进一步的,在text段传输的过程中通过随机数加扰,更能提高text段传输的安全性,从而确保审计的可靠性。

在一些实现方式中,所述终端设备还包括部署在第一域的第一随机数发生器和部署在第二域的第二随机数发生器。这里的第一随机数发生器可以是前述实现方式中的随机数发生器,也可以是另一个随机数发生器。所述控制流管理模块获取的待审计信息中还包括随机数。所述第一随机数发生器在所述程序被执行时被调用而产生所述随机数,该随机数被写入所述跟踪器的第三寄存器中,然后所述跟踪器在采集所述控制流信息的时候访问所述第三寄存器获得寄存器中当前存储的随机数,并与当前的控制流信息一起作为一条待审计信息。所述审计模块具体被配置为获取所述第一随机数发生器在所述程序执行过程中产生的最后一个随机数ry以及获取所述第二域中预置的随机数发生次数n;根据所述n触发所述第二随机数发生器产生n个随机数,并将其中第n个随机数rn与所述ry比较,当所述rn与所述ry相同且其他待审计信息匹配所述审计规则时确定审计通过。

换句话说,(在第一域)第一随机数发生器所述程序被执行时产生多个随机数,每个随机数都在产生之后被写入跟踪器的寄存器,之后跟踪器采集控制流信息的时候一并从寄存器中读取该随机数,和控制流信息一起传递到第二域。第二域的审计模块可通过多种方式从传递过来的随机数中确定出第一随机数发生器最后一次产生的随机数rx,然后获取与该随机数rx对应的随机数发生器发生次数n,此n是根据程序正常执行的情况预置在第二域中的。之后审计模块调用第二随机数发生器产生n个随机数并选取其中第n个随机数,如果两种方式获得的随机数相同,则说明第一域中的程序的执行没有被干扰过。

本申请中出现的“审计规则”可以在不同的实现方式下有不同的理解,例如在待审计信息中只有控制流信息时,审计规则可以理解为只包含审计控制流的规则,而当待审计信息中出现其他信息,如数据流信息、进程标识、随机数、text段等信息时,审计规则可以理解为还包含匹配进程标识的规则,和/或审核随机数、text等信息的规则。在其他一些实现方式中,“审计规则”也可以理解为只包含控制流审计规则,其他信息的匹配或审核属于另外的模型或规则。“审计规则”的实现方式有多种,可以是自动机、审计模型,也可以是一张表、一个列表、一个判断语句等等。复杂的审计规则可以通过机器学习的方式实现。例如,可以在终端设备或服务器端模拟运行所述程序,然后学习获得所述程序的执行特征(或称为模型),之后通过将程序的实际执行流程等信息与所述执行特征匹配确定该实际执行流程是否合法。

在一些实现方式中,所述跟踪器的全部组件或部分组件通过硬件划分的方式或软件权限管理的方式放到第二域中,所述第二域的安全性高于所述第一域。通过这种方式可以保证跟踪器的安全性,前述实现方式中对跟踪器的审核就不是必须的了,当然也可以仍然执行审核,采用双重机制保障跟踪器的安全。

在一些实现方式中,在所述程序的多个位置插入触发指令,用于触发跟踪器采集特定位置的控制流信息;在另一些实现方式中跟踪器可以不需要触发指令的触发,而是采集程序所有的控制流信息。

第二方面,本申请还提供一种审计方法,该方法应用于部署有第一域和第二域的计算机系统中。当位于所述第一域中的程序被执行时,通过跟踪器在所述第二域中获取待审计信息,所述待审计信息包括所述程序的控制流信息。在所述第二域中根据审计规则对所述待审计信息进行审计,当所述待审计信息匹配所述审计规则时确定审计通过。所述跟踪器可以全部或部分部署在所述第二域中。

将该审计方法应用于安全控制之后,当审计通过再允许执行下一步操作,例如允许所述程序或与所述程序相关的下一个程序对所述第二域的某个安全程序执行访问。

在一些实现方式中,所述程序开始执行之时才开启所述跟踪器,然后在第二域中同步或异步获取跟踪器采集的待审计信息;在另一些实现方式中,所述程序被执行中间某个关键代码时才开启所述跟踪器,或者跟踪器可以在系统启动之后就一直是开启状态。

在一些实现方式中,所述待审计信息还包括所述程序的数据流信息。

在一些实现方式中,在对所述控制流信息进行审计之前,在所述第二域中对所述跟踪器进行审核,审核通过后再对所述控制流信息进行审计。

在一些实现方式中,在所述通过跟踪器获取待审计信息之前,获取所述执行所述程序的进程的进程标识,并将所述进程标识存入所述跟踪器的第一寄存器中;然后获取所述跟踪器采集的待审计信息,此时该待审计信息包括所述控制流信息和所述控制流信息被采集时所述第一寄存器中的进程标识。换句话说,所述进程标识为所述跟踪器采集所述控制流信息时从所述第一寄存器中读取的当前的进程标识。然后,根据所述进程标识查找与所述进程标识匹配的审计规则,并根据查找到的审计规则对所述控制流信息执行审计。

在一些实现方式中,所述计算机系统还包括部署在所述第一域的第一随机数发生器,所述第二域中包含所述程序的text段。在所述程序被执行之前,在所述第一域中调用所述第一随机数发生器以产生随机数rx,并将所述随机数rx存入所述跟踪器的第二寄存器,以及根据所述随机数rx和执行所述程序的进程的text段计算得到哈希值h1。获取所述跟踪器采集的待审计信息,此时所述待审计信息中包括所述控制流信息和所述随机数rx,其中所述rx由所述跟踪器访问所述第二寄存器获得。在所述第二域中获取所述哈希值h1,根据所述随机数rx和所述第二域中包含的所述text段计算得到哈希值h2,比较所述h1和h2,当所述h1和h2相同且其他待审计信息匹配所述审计规则时确定审计通过。在一些实现方式中,所述计算机系统还包括部署在第一域的第一随机数发生器和部署在第二域的第二随机数发生器。在所述程序被执行时,在所述第一域中调用所述第一随机数发生器产生随机数,并将所述随机数写入所述跟踪器的第三寄存器。通过所述跟踪器获取待审计信息,所述待审计信息中包括控制流信息和该控制流信息被采集时所述第三寄存器中的随机数。在所述第二域中获取所述第一随机数发生器在所述程序执行过程中产生的最后一个随机数ry以及获取所述第二域中预置的随机数发生次数n.。然后根据所述n触发所述第二随机数发生器产生n个随机数,并将其中第n个随机数rn与所述ry比较,当所述rn与所述ry相同且其他待审计信息匹配所述审计规则时确定审计通过。

应理解的是,上述需要随机数的实现方式中并不限定每一条待审计信息中都要包含随机数。

第三方面,本申请还提供一种计算机可读存储介质,该存储介质包括计算机可读指令,当所述计算机可读指令被一个或多个处理器执行时用于实现如前述任意一种方法。

第四方面,本申请还提供一种计算机程序产品,该计算机程序产品中包括计算机可读指令,当所述计算机可读指令被一个或多个处理器执行时用于实现如前述任意一种方法。

第五方面,本申请还提供一种计算机系统,该计算机系统的硬件层包括跟踪器、处理器以及存储器。该计算机系统逻辑上又可分为第一域和第二域。所述处理器被配置为读取所述存储器中的计算机可读指令并执行所述计算机可读指令以实现启动所述跟踪器,以及执行位于所述第一域的程序。而所述硬件跟踪器被配置为在所述程序执行时,采集与所述程序相关的待审计信息。,进一步的所述第二域的安全性可以高于(或等于)所述第一域。

跟踪器的采集待审计信息的动作在一些实现方式中是由处理器在执行所述程序的时候由所述处理器触发的,例如所述程序中被插入有触发指令;在另一些实现方式下是处理器在其他情形下触发的,也可能是跟踪器启动后自主执行的。

附图说明

为了更清楚地说明本申请提供的技术方案,下面将对附图作简单地介绍。显而易见地,下面描述的附图仅仅是本申请的一些实施例。

图1为本实施例提供的一种计算机系统的结构示意图;

图2为本实施例提供的一种终端设备的结构示意图;

图3为基于图2的一种安全控制方法的流程示意图;

图4为本实施例提供的一种终端设备的结构示意图;

图5为基于图4的一种安全控制方法的流程示意图;

图6为本实施例提供的一种终端设备的结构示意图;

图7为基于图6的一种审计方法的流程示意图;

图8为本实施例提供的一种终端设备的结构示意图;

图9为基于图8的跟踪器采集信息的示意图;

图10为基于图8和图9的一种审计方法的流程示意图;

图11为本实施例提供的一种终端设备的结构示意图;

图12为基于图11的跟踪器采集信息的示意图;

图13为基于图11和图12的一种审计方法的流程示意图;

图14为本实施例提供的一种终端设备的结构示意图;

图15为本实施例提供的一种终端设备的结构示意图;

图16为本实施例提供的一种终端设备的结构示意图;

图17为基于图16的一种审计方法的流程示意图;

图18为本实施例提供的一种服务器及所在网络的示意图;

图19为本实施例提供的一种服务器及所在网络的示意图;

图20为本实施例提供的一种终端设备的逻辑结构示意图。

具体实施方式

实施例一

请参考图1,为本实施例提供的一种计算机系统的结构示意图。该计算机系统包括硬件层,硬件层包括处理器150、存储器160以及跟踪器170。该计算机系统具体可以为终端设备,固定终端或移动终端都可以。固定终端例如为个人电脑、销售终端(pointofsale,pos)、或自动取款机等;移动终端例如为智能电话、膝上型计算机、数字广播终端、个人数字助理、便携式多媒体播放器、或车载导航系统等等具有移动性质的计算机。。应理解的是,除了终端设备这种类型以外,本申请任意实施例提供的方法也可以应用于其他类型的计算机系统,例如服务器。

处理器150可以是单核或多核处理器。该计算机系统中也可以包含多种类型的处理器。存储器160可以包括以下类型中的一种或多种:闪速(flash)存储器、硬盘类型存储器、微型多媒体卡型存储器、卡式存储器(例如sd或xd存储器)、随机存取存储器(randomaccessmemory,ram)、静态随机存取存储器(staticram,sram)、只读存储器(readonlymemory,rom)、电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory,eeprom)、可编程只读存储器(programmablerom,prom)、磁存储器、磁盘或光盘。

在其他一些实施例中,存储器160也可以包括因特网上的网络存储设备,该计算机系统可以对在因特网上的存储器160执行更新或读取等操作。

从软件的角度,该计算机系统被划分为两个域:第一域和第二域,这两个域由同一个处理器运行,但是运行在处理器的不同状态下。这两个域中分别运行有第一和第二操作系统,第一和第二操作系统之上分别运行有多个第一应用和多个第二应用。

需要说明的是,第一操作系统和第二操作系统的类型可以相同,也可以不同,还可以是同一个操作系统的两种不同的状态,例如用户态和内核态,即第一域和第二域分别为同一操作系统的两种状态。

在第一操作系统中设置有待保护的程序110,该待保护的程序在运行过程中通过跟踪器170采集该程序的运行相关的控制流信息等,然后tracer管理模块130可以获取这些信息。待保护的程序110有可能是第一应用的一部分。

“待保护的程序”为任意一段需要保护的程序,该程序必须按照原本的执行流程被执行,不能被篡改或被绕过。待保护的程序可以位于系统中的任意位置,可以位于下述实施例中的ree侧,也可以位于tee侧。例如,待保护的程序例如可以为中的内核模块(后缀名为ko的模块)、ca鉴权模块等。

特征信息等信息的获取可通过如下方式:在功能代码的一个或多个位置分别插入一个或多个用于触发采集信息的触发指令,以生成待保护的程序110。当待保护的程序110运行到这些触发指令处的时候,触发跟踪器170采集待保护的程序110的相关信息。这些信息(下文称之为待审计信息)可以包括以下信息中的一种或多种:用于做控制流审计的与代码运行相关的控制流信息、用于数据审计的代码执行过程中的动态数据、用于保证信息传输安全的随机数、以及用于在并行审计中标识待保护的程序的进程id(processidentification,pid)等。

代码的执行过程中被操作的非只读数据是动态数据,只读数据为静态数据。例如,在发明内容部分关于控制流的解释的例子中,y的值就属于动态数据。再例如,text段中包含代码和数据,这些数据通常都是静态数据。动态数据可以通过跟踪器跟踪load指令和store指令获取,例如代码x=y,对应于一个load指令和一个store指令,load指令将y的值从y的内存中读到寄存器中,store指令将寄存器中的值写到x的内存中,内存数据的读写一般都要通过load指令和store指令,所以跟踪这两个指令可以获得动态数据。

待保护的程序110的生成可以在除该计算机系统的另一个计算机系统上。触发指令的内容及具体的插入位置等可以由开发人员确定,也可以通过将特定规则输入计算机后由计算机自动生成。触发指令可以是开发者在开发时手动插入到待保护的程序中的,也可以是通过计算机自动插入的。

需要说明的是,tracer管理模块130的具体实现有多种,除了获取(或管理)跟踪器170收集的信息之外,还可以对跟踪器170本身进行管理,例如在计算机系统启动阶段打开和初始化跟踪器170、以及在某些情况下审核tracer等操作。另外,针对不同类型的程序,程序进入与启动操作可能会有所不同。

审计触发模块120用于向第二操作系统中设置的审计模块140发送触发信息,以触发审计模块140开始执行程序110的审计操作。具体的,审计触发模块120通过将审计规则11与tracer管理模块130获取的控制流进行比较,若控制流符合审计规则11,则继续后续的功能操作。若控制流不符合审计规则,则说明程序110的执行存在问题,终止当前操作和/或返回错误信息给第一操作系统。审计触发模块120也可能是待保护的程序110的一部分。

审计规则11被存储在存储器160中。审计规则11的种类可能有多种。自动机是审计规则的一种具体实现方式。

需要说明的是,触发信息从一个域被发送到另一域时,一般都会涉及到两个域的切换。两个域切换的方法和过程与本申请应用的系统有关,本实施例不做限定。

可见,利用本实施例提供的方法,可以在一个域中对另一域的待保护代码的执行过程进行控制流审计以保证该代码的正常执行,有效避免所在域被权限提升之后该代码被绕过,从而避免由此可能造成的安全漏洞。这里某一域被权限提升意指该域的较高或最高权限被获取。

进一步的,若跟踪器(或tracer管理模块130)获取了除控制流信息之外的其他待审计信息,那么审计模块140可以对这些信息一并进行处理,以进一步增强本申请的适用性或安全性。

实施例二

下面结合trustzone技术框架以及操作系统来示例性地介绍本申请提供的控制流审计方法以及其他多种方法的实施方式。

请参与图2,为本实施例提供的一种终端设备的装置结构示意图。该终端设备包括硬件层,硬件层包括处理器250、存储器260以及coresight270。coresight270为一种典型的硬件跟踪器。coresight270在终端设备200运行的整个时段或部分时段处于打开状态。

存储器260中包括被设置为只读的只读内存区260-1和其他内存区260-2。当然存储器260还可以包括其他类型的存储介质,可参考前述实施例,在此不再赘述。

终端设备200上包含两个域:富执行环境(richexecutionenvironment,ree)和可信执行环境(trustedexecutionenvironment,tee)。这两个域中分别运行有操作系统和一种tee侧操作系统(例如开源的op-tee操作系统)。操作系统和teeos又划分为用户态和内核态两种状态。

ree侧的用户态中设置客户端应用(ca),ca在访问tee侧的可信应用(ta)之前需要调用内核态的一段鉴权程序210,这段代码就是前述实施例中的待保护程序110。在其他一些实施例中,该代码也可以理解为是ca的一部分代码,所以ca也属于本申请能够保护和监控的对象。

鉴权程序210属于ree与tee通信前握手程序中的一部分。这段握手程序分为两部分:1.ree提出握手;2.tee处理握手请求并决定是否握手成功。鉴权程序210实现的是第1部分即ree提出握手。鉴权程序210的功能主要包括:1.收集ca身份信息;2.构造握手请求;3.将身份信息和握手请求进行校验,生成校验和;4.将ca身份信息,握手请求和校验和发给tee。在现有的架构里,tee拒绝没有经过握手过程而发送过来的请求。

该握手程序是由一系列函数代码及其所需要处理的数据组成的。安全攻击行为可以在函数的执行顺序、相应的数据、或者函数执行顺序及数据的组合中,找到漏洞,从而破坏这段代码执行的完整性,造成后续安全漏洞。例如,仿冒的ca可以绕过身份信息的收集过程,发送不属于自己的伪造的身份信息,假冒合法ca的身份。

本实施例中的鉴权程序210已经不再是现有技术的鉴权程序,鉴权程序210的多个位置分别被插入多个coresight触发指令。触发指令用于触发coresight270采集代码执行的相关信息。具体的,coresight触发指令可以是一段程序,该程序的功能是:1.配置coresight270的数据传递寄存器;2.使coresight270开始采集待审计信息。鉴权程序210的这多个位置可理解为触发采集信息的“采集点”。

ree侧内核态中还设置有smc调用模块220,该模块主要用于向审计模块240发送用于触发审计的触发消息。本实施例中,smc调用模块220实现为鉴权程序210中的一部分,即鉴权程序210自己发送触发审计的触发消息。在其他实施例中,smc调用模块220和待保护的程序也可以独立。

以指纹验证为例,图3示出了控制流完整性审计(下述简称为控制流审计)的过程。用户在开机或进行某项支付操作时输入自己的指纹,激活某个ca,该ca又调用鉴权程序210,而后鉴权程序210开始执行(s110)。在鉴权程序210的执行过程中,由于在代码中设置了多个coresight触发指令,在执行到每个触发指令时,coresigt270就可以执行特征信息的收集操作(s120),将这些信息直接或经过转化后作为鉴权程序270的控制流信息存储起来。鉴权程序210执行到最后,smc调用模块220通过smc指令向审计模块240发送触发消息(s130),具体的,该触发消息中包括ca身份信息等内容。smc调用模块220所在位置可理解为触发审计的“审计点”。

smc调用模块220向审计模块240发送触发消息时涉及到ree到tee的切换,需要调用smc(securemonitorcall)指令,先从ree切换到trustzone的中间模式即监控模式(monitormode),然后监控模式再把自己切换到tee。smc是trustzone技术框架的基础技术,更多实现在此不再赘述。

当审计模块240接收到触发信息之后,从存储器260中获取鉴权程序210的控制流信息,或调用控制流管理模块230获取控制流信息(s140和s150)。

具体的,控制流管理模块230从coresight270中获取控制流信息(s140),并返回给审计模块240(s150)。更具体的,之前coresigt270将控制流信息存储到coresigt270内部的某存储介质中,控制流管理模块230从该存储介质中读取控制流信息,并将该控制流信息直接存储到存储器260中,或对该控制流信息做特定处理之后再存储到存储器260中,或直接返回给审计模块240。在其他一些实施例中,控制流管理模块230和审计模块240也可以合并为一个模块。

审计模块240还根据审计规则21获取用于审计该控制流的自动机。具体的,审计模块240根据审计规则21生成一个自动机实例(s160)。审计模块240通过将控制流信息或转化后的信息输入自动机实例实现对控制流的审计(s170)。审计成功之后返回结果给ree侧,ree继续将用户输入的指纹信息发送给tee,然后由tee侧的ta执行指纹信息的验证,例如,tee侧调用某个鉴权ta验证指纹信息是否在预置的合法身份信息库中存在匹配,如果存在匹配,则向ree侧返回指纹验证成功。审计不成功则tee终止当前握手,向ree返回握手不成功消息,或返回用于指示安全问题的信息。

自动机可以理解为一个由软件代码实现的函数,该函数的属性中包含一个二维数组,该数组中的每个元素表示自动机的一种状态,例如第x行且第y列的值为v,那么自动机代码将会表述为若自动机当前处于状态x,且当前输入为事件y,则将自动机的状态转变到v。每种状态拥有各自的属性,分别为“初始”和“终止”,具有“初始”属性的状态有且只有一个,但具有“终止”属性的状态可以有多个。自动机实例就是基于前述自动机(可理解为一个模板)创建的一个具体的运行时自动机实例,其创建之初的状态为属性为“初始”的状态。审计模块240利用自动机执行审计的方法具体为:将获取到的控制流信息转化为事件序列,以此事件序列驱动自动机实例进行状态转换。全部事件都输入完毕后,检查自动机的状态。如果在属性为“终止”的某个状态,则审计成功;否则审计失败。

控制流管理模块230可以管理该控制流信息(s180),比如预处理、存储等。在其他一些实施例中,控制流管理模块230从coresight270中获取并管理控制流信息(s140和s180)的步骤也可以不需要审计模块240的调用触发,或者说在审计模块240的触发之前就把控制流信息从coresight270中获取并存储到存储器260中。

可见,tee侧的审计模块240在安全应用ta被调用之前对鉴权程序210的控制流进行了审计,审计成功(即鉴权程序210可靠执行)之后才真正实现对ta的调用,这样可有效防止非法ca绕过鉴权程序210。鉴权程序210若执行不完整,非法ca的身份信息就不能被正常获取,进而非法ca就可以向tee侧发送不属于自己但能够通过验证的伪造身份信息给tee侧,然后tee侧根据该伪造身份信息验证通过该非法ca,使得该非法ca可以和tee侧通信,进而造成系统的安全漏洞。

进一步的,本实施例可以在终端设备启动阶段对内存区域进行划分,划出一块只读内存区260-1,将鉴权程序210加载到该只读内存区260-1中,从而避免鉴权程序210的代码被非法修改,进一步保证终端设备的安全性。

实施例三

根据上述实施例的介绍可知,coresight270用于收集控制流信息(以及其他待审计信息),所以coresight270本身的安全性是系统的基础。为进一步确保安全性,在tee侧任意模块从coresight270的存储介质中读取数据之前需要审核coresight270。

参考图4,在图3的基础上增加了tracer审核模块230b,用于审核coresight270。参考图5虚线方框所示,smc调用模块220向tracer审核模块230b发送触发消息(s130)。tracer审核模块230b先审核coresight270(s130a),审核通过后才向审计模块240发送审核通过的消息(s130b),用以触发审计模块240执行接下来的操作。

审核coresight270主要是判断coresight270的寄存器有没有被修改过。具体的,获取该寄存器当前的值和coresight270被初始化时该寄存器的初始值,比较二者,若一致,则审核通过,反之则审核不通过。这里审核的“寄存器”可以包括coresight270中的所有寄存器或其中任意一个或多个认为关键的寄存器。

“初始值”在coresight设计时就定好了,写在启动代码里,审核的时候获取代码中记录的该“初始值”,然后与当前值比较。

图5其他步骤与图3类似,可参考前述描述,在此不在赘述。

在其他一些实施例中,审计模块240可仍然如图3所示接收到触发消息,然后有选择地调用tracer审核模块230b。换句话说,审计模块240可以决定coresight270需不需要被审核。

可见,通过上述方法在审计之前审核coresight270,可以提高整个审计过程的可信性,从而进一步提高系统的安全性。

实施例四

本申请还提供一种并行审计的方法,能够在多个待保护程序同时运行的场景中,利用一个跟踪器实现多个待保护程序的控制流的并行审计。该并行审计的方法可以融合在前述任意实施例中实现。

图6为本实施例提供的并行审计方法的装置示意图。coresight270设置有寄存器271,该寄存器可以由软件写入任意值。在ree侧存在待保护的程序210a、210b和210c。其中210a是前述实施例中的鉴权程序210,待保护的程序210b和210c为其它代码,本实施例不做限定。审计模块240包含三个自动机实例a、b和c。其他模块可参考前述实施例描述。

与图3不同的是,程序210a、210b和210c分别被三个pid=a,pid=b和pid=c的进程执行,执行到coresight270触发指令处,coresight270触发指令触发获取执行当前程序的进程的pid(processidentification),并将该pid写入寄存器271。coresight270触发指令触发coresight270收集信息时,不仅收集该采集点的控制流信息,还要从寄存器271中读取该控制流信息产生的时刻寄存器271中存储的pid的值,和该控制流信息关联存储起来作为待审计信息。当程序210a、210b和210c中任意一个程序执行到触发审计的审计点时(例如图3中的s130),触发tee侧的审计模块240执行审计。如图5示出的实施例那样审计之前先审核coresight270也可以。

需要说明的是,获取并写入进程pid的代码可以理解为一个或多个进程标识获取模块,在图中未示出。

通过上述方式,每一条控制流信息以及产生该控制流信息的进程就被存储下来,以便于后面针对不同的控制流信息利用不同的自动机实例分别进行审计。

审计被触发后,审计模块240获取待审计信息并根据待审计信息中的pid查找或创建匹配的自动机实例,并将待审计信息中的控制流信息输入该自动机实例,每个自动机实例分别实现针对每个待保护程序的控制流审计。

在一种实现方式下,如图7所示,审计模块240从所有待审计信息中获取下一条控制流信息,该条待审计信息包含控制流信息和pid(s701)。关于审计模块240如何从coresight270直接或间接获取待审计信息的方式可参考前述实施例。获取该待审计信息之后,审计模块240判断该待审计信息是否为空(s702),如果该待审计信息不为空,则根据该待审计信息中的pid查找匹配的自动机实例(s703)。判断是否找到自动机实例(s704),若没有找到自动机实例,则新建一个标识为该pid的自动机实例(s705);若找到自动机实例或创建自动机实例之后,将控制流信息输入该自动机实例(s706),以将该自动机实例往前推进一步。之后返回步骤s701。

若步骤s702判断获取到的待审计信息为空,亦即当前所有的待审计信息都按照前述方法处理完成之后,获取发送本次审计触发消息的进程的pid(s707)。具体的,ree侧的ca在做跨域调用时通常都会将该ca的进程的pid以及想要调用的ta的标识和参数等存储到共享内存中,这样tee侧的模块就可以从共享内存中获取该进程的pid的值。查找标识为该pid的值的自动机实例(s708),若这样的自动机实例不存在(s709),则对于本次审计失败。若这样的自动机实例存在(s709),则判断该自动机实例当前是否在属性为“终止”的状态(简称终止状态),若是,则审计成功,若否,则审计失败。

在另一种实现方式下,审计模块240先获取发送本次审计触发消息的进程的pid,从待审计信息中获取包含相同pid的待审计信息,然后对所获取的每一条待审计信息执行以下操作:根据获取的pid查找匹配的自动机实例,若没有找到则创建一个标识为该pid的自动机实例;若找到,则将该待审计信息输入该自动机实例。所有待审计信息均处理完成之后,若该自动机实例在属性为“终止”状态,则审计成功,否则审计失败。

需要说明的是,本实施例中与每一条待审计信息匹配的(或称对应的)自动机实例为标识为pid的自动机实例,该pid为该待审计信息中包含的pid的值。例如pid=a的待审计信息,其匹配的自动机实例是标识为a的自动机实例。在其他一些实施例中,待保护的程序的进程pid和对应的自动机实例的标识不一定要完全一致,不一致但存储二者的对应关系或已知二者的转换关系也可以实现本实施例。

通过以上并行审计的方法,本实施例提供的控制流审计可以在仅有一个跟踪器的终端设备中同时审计多个待保护的程序,这样审计效率更高,方法的适用场景也更广。

实施例五

为了进一步减少待保护程序被窥探的可能性,本实施例提供一种结合随机数来进行控制流审计的方法。

图8为本实施例提供的一种终端设备的结构示意图。该终端设备中包括两个硬件的(伪)随机数发生器280a和280b,这两个随机数发生器通过trustzone的硬件划分机制分别被划分到ree侧和tee侧,即随机数发生器280a可以被ree侧访问(tee侧可访问或不可访问均可),随机数发生器280b仅能被tee侧访问。另外,coresight270中还设置有寄存器272,该寄存器可以由软件写入任意值,coresight270产生的每一条记录都会附带产生该记录的时刻该寄存器的值。

前述实施例中提到过自动机的状态具有“初始”和“终止”两种属性,本实施例中在设计自动机时,为每种状态都增加“数据传输”和“随机数发生器访问次数”两个属性,或者根据需求为其中的一种或多种状态增加这两个属性。

根据鉴权程序210的执行流程在鉴权程序210中挑选出多个位置,这多个位置称之为“随机数产生点”,在随机数产生点插入代码,出入的代码实现调用随机数发生器280a产生一个随机数并将该随机数写入coresight270的寄存器272。这样,鉴权程序210在执行时,每执行到随机数产生点,就是调用一次随机数发生器280a并将产生的随机数写入寄存器272。

在前述实施例中,鉴权程序210的多个位置被插入了coresight触发指令,用于触发coresight270采集控制流信息(参考图3),这多个位置可以称之为“采集点”,本实施例中提出的“随机数产生点”和“采集点”可以完全重叠,也可以部分重叠,也可以完全不重叠。当一个“点”产生随机数,但是并非“采集点”,那么该随机数将会伴随着相邻的下一个“采集点”被coresight270采集,进而被tee侧获得。如图9所示,鉴权程序210中包括至少4个采集点(圆形所示)cp1-cp4和至少5个随机数产生点(方形表示)gp1-gp5,其中gp3和cp3,gp5和cp4分别重叠。若重叠,则如图所示,该位置随机数的产生指令通常在coresight触发指令之前。在鉴权程序210执行到不重叠的随机数产生点gp1时,调用随机数发生器280a产生随机数r1,并将该随机数写入寄存器272,然后执行到采集点cp2时,触发coresight270采集该条控制流信息以及寄存器272中的当前随机数r1(参考图9中的步骤s120)作为一条待审计信息。

设置了随机数产生点以后,在编码自动机时,手工或自动计算一下自动机运行到每个状态时经过了多少次随机数产生点,据此来设置每个状态的“随机数发生器访问次数”属性。例如,继续参考图9,程序被执行时经过cp1-cp4四个采集点,分别对应e1-e4四个事件,根据执行流程自动机可能被编码为:(s0)–e1->(s1)–e2->(s2)–e3->(s3)–e4->s4。那么,s0,s1的随机数发生器访问次数属性的值为0;由于e1和e2中间有1个随机数产生点gp1,因此s2的随机数发生器访问次数属性的值为1;依此类推,s3和s4的随机数发生器访问次数属性的值分别为3和5。

按照前述示例,ree侧终止状态s4之前最后一次产生随机数是在gp5,该随机数需要被记录,而携带该随机数的是cp4对应的待审计信息,该待审计信息里包含控制流信息e4(或理解为“事件”)和该随机数(参考图9),因此可以将e4之后的状态s4的“数据传输”属性的值设置为1,以便于在后续自动机实例运行过程中根据该属性将该ree侧最后一次产生的随机数记录在tee侧。其它状态的“数据传输”属性的值可以随意设置。当然这种设置为1或非1,true或false的方式仅是举例,本领域技术人员容易根据本实施方式的实质想到其它设置方式,亦在本申请的保护范围之内。

按照前述实施例,审计模块240被触发后,生成自动机实例并根据获取的待审计信息驱动自动机实例进行状态变换以审计控制流。本实施例中对自动机实例做出以下变更:自动机实例带有一个变量v,用于记录随机数。状态变换规则发生以下变更:接收到待审计信息且状态被推进之后,如果推进后的状态的“数据传输”属性的值不为1,则忽略该待审计信息中携带的随机数,若为1,则将该随机数赋值给变量v。审计完成时,如果自动机实例没有处于终止状态,则审计不成功;如果自动机实例处于终止状态,则从随机数发生器280b中一次获取n个随机数,所述n为该终止状态的随机数发生器访问次数属性的值,然后将第n个随机数与变量v的值比较,若一致,则审计通过,若不一致,则审计不通过。

具体的,如图10所示,审计模块240中的任意一个自动机实例执行下述步骤:获取下一条待审计信息(s1001),其中包含控制流信息e[next]和随机数r[next],判断是否为空(s1002),如果为空,则说明所有待审计信息都处理完了;如果不为空,则根据该e[next]和s[current]将自动机实例推进到下一个状态s[current](s1003)。获取推进后的状态s[current]的“数据传输”属性的值(s1004),判断该值是否为1(s1005),若不为1,返回s1001;若为1,则该随机数r[next]赋值给变量v(s1006)。在所有待审计信息都处理完成之后,判断s[current]是否为终止状态(s1007),若否,则审计失败。若s[current]为终止状态,则获取s[current]的随机数生成器访问次数的属性值n(s1008),并根据n调用随机数发生器280b产生n个随机数并记录第n个随机数rn(s1009)。之后判断rn和变量v的当前值是否相同(s1010),若相同,则审计成功,否则审计失败。

在其他实现方式中,“数据传输”属性也可以不设置,即可以用变量v记录每个随机数,每次记录都覆盖之前的值。

需要说明的是,本实施例的目的将ree侧待保护代码正常的执行流程中最后一次产生的随机数v与tee侧产生的随机数rn进行匹配,rn是根据该执行流程下自动机终止状态里预先设置的随机数生成器访问次数n产生的。为了实现该目的,在设计具体方案时存在很多可能的变化,例如如果在自动机实例状态转换规则中先判断当前状态的数据传输属性,再推进当前状态到下一个状态,那么按照前述举例,状态s3的“数据传输”属性应该被设置为1,以便于记录最后一次产生的随机数,等等这些变化本领域技术人员容易想到,本申请在此不一一列举。

只是用自动机的话只能保证一个进程调用了所有该调用的点,不能保证这些点只被它调用了。如果另一个进程切入进来调用了一些安全流程,只靠自动机是审计不出来的。另一个进程可能只是切进来窃取一些数据或者注入一些假数据,可能并不会触发跨域调用,它的异常行为通过自动机审计不出来,但是如果它调用了“随机数产生点”,随机数序列就会发生变化,自动机就会发现随机数不匹配,进而发现这个过程受到了干扰。因此,通过上述方式,可以在tee侧及时发现ree侧进程是否被干扰,进一步提高系统的安全性。

实施例六

在前述实施例中介绍了控制流的审计方法,能够很大程度上检测出待保护程序被修改或被绕过的情形,从而及时发现系统问题,避免出现系统漏洞。下面介绍一个实施例在对控制流审计的同时,还可以进行身份的审计,进一步提高安全性。

(静态的)程序存储在介质中时,其代码和静态数据(也称之为常量)放在一个存储区域里,在某些系统中叫做text段。(动态的)程序由进程运行。虚拟内存技术使得每个进程都可以独占整个内存空间,地址从零开始,直到内存上限。每个进程都将这部分空间(从低地址到高地址)分为多个部分,其中一个部分为text段,这段内存中包括整个程序的代码以及静态数据(即常量)。

进程的text段包含进程所执行的程序的全部指令,和进程pid或进程名字相比,text段更难伪造,因此本实施例中将这段内容理解为进程的“身份”,对这部分内容的审计称之为“身份”审计。

图11为本实施例提供的一种终端设备的结构示意图。该终端设备中包括1个硬件的(伪)随机数发生器290,该随机数发生器290通过trustzone的硬件划分机制被划分到ree侧。另外,coresight270中还设置有寄存器272,该寄存器可以由软件写入任意值,coresight270产生的每一条记录都会附带产生该记录的时刻该寄存器的值。

除“初始”和“终止”两种属性,本实施例中在设计自动机时,为每种状态增加“数据传输”属性,或者根据需求为其中的一种或多种状态增加这个属性。

如图11所示,鉴权程序210中存在一个自采集模块210a,该自采集模块210a用于调用随机数发生器290产生一个随机数,将该随机数写入coresight270的寄存器272,并产生一段加扰过的数据流。该加扰过的数据流的内容为:将产生的该随机数与ree侧当前进程的text段拼接在一起,拼接的方式为随机数在前,text段在后,并对拼接后的数据做哈希运算(例如sha256算法)得到的哈希值h1。自采集模块210a在计算完含有随机数的流头部后就将随机数用其他数据覆盖。要使用随机数做计算,随机数必须被读入到寄存器里,甚至可能会被写到内存里,因此这里说的“覆盖”就是从寄存器或内存中将随机数的值清除掉,防止黑客利用。

在其他一些实施例中,随机数可以在text段之后。随机数在前面有好处:实际的处理并非一定要先拼好再计算,可以是流式地计算。随机数在前可以尽快完成和随机数有关的计算,从而将随机数的值从内存或寄存器中清除掉。

在其他一些实施例中,被拼接的可以不是text段的原始内容,可以是text段包含的内容的摘要或被压缩后的text段。计算摘要的算法例如可以为sha256或md5等。

如图12所示,自采集模块210a的代码设置在鉴权程序210在之前的实施例中首次触发coresight270的位置之前。也可以将该段代码210a和鉴权程序210一起理解为待保护的程序。因为也属于待保护的程序,所以在自采集模块210a内部也可以设置采集点(图11未示出)。

另外,在tee侧复制一份合法的ree侧进程的text段。具体的,在版本发布过程中,编译tee侧操作系统时,把ree侧的text段包含的全部内容硬编码到tee侧操作系统中。

需要说明的是,本实施例中假设预先知道这个系统上ree侧能运行的所有合法的ca。ca是一段程序,它在运行时是一个进程。这里的text段指得是所有合法ca的text段。因此,“ree侧的text段”就是预先准备好的所有合法ca的text段,包括每个ca的代码和常量。

在其他一些实施例中,硬编码进tee侧的也可以是text段原始内容的摘要或压缩后的text段。

如图12所示,自采集模块210a先执行,并将该代码的入口设置为“采集点”(p1),触发coresight270收集控制流信息以及寄存器272中的随机数,该随机数就是自采集模块210a产生并写入寄存器272的那个随机数。由于自采集模块210a也产生了随机数并写入了寄存器272,因此该采集点也是随机数产生点(p1)。在编码自动机时,将该采集点p1对应的事件输入自动机后得到的状态的数据传输属性设置为1。例如,假设p1触发coresight270收集的特征信息对应的事件为ep1,ep1输入之前自动机状态为s0,输入之后自动机状态变换为s1,即(s0)–ep1->(s1),那么s1对应的数据传输属性的值设置为1。

需要说明的,因为本实施例只需产生一次随机数,所以也可以让该随机数伴随着除p1之外的其它的采集点传递到tee侧。

ree将自采集模块210a获取到的哈希值h1通过trustzone提供的常规手段传递给tee,具体的,传递给审计模块240。这个可以发生在哈希值产生之后的任何时间,但建议在审计模块240被触发之前传递到。

参考图13,审计模块240被触发后,其自动机实例的执行过程与图10类似,只是,随机数只产生了一次(参考图12随机数产生点p1),又因为设置了相应状态的“数据传输”属性,所以该随机数在自动机实例运转结束后会被记录到变量v中,参考图13的步骤s1301-s1306。

需要说明的是,在其他实施例中,s1301-s1306这几个步骤也可以简化一下,因为只有一个随机数,所以v第一次被赋值以后就可以取消对数据传输属性的获取和判断步骤。编码人员容易想到的类似变形方案很多,本申请不一一赘述。

继续参考图13,若最终状态s[current]是终止状态,则将v的值和硬编码得到的text段或text段的摘要拼接在一起,拼接方式为v的值在前,text段或text段的摘要在后,将拼接后的数据做哈希运算得到哈希值h2(s1308),比较h1和h2(s1309),若两者相同,则审计通过,否则审计不通过。在其它实施例中,如果硬编码的是压缩后的text段,这里需要解压缩。

前述任意实施例提到的随机数发生器是硬件实现,在其他实施例中,随机数发生器也可以用软件实现。例如将图8中的两个随机数发生器280a和280b换成软件实现的两个随机数发生器,并将这两个软件随机数发生器分别置于能够被ree访问的存储区域和仅能被tee访问的存储区域中。

通过本实施例提供的方法,可以实现身份和控制流的联合审计,进一步提高了系统的安全性。进一步的,在ree向tee传输身份信息的过程中,采用了随机数进行加扰,确保了身份信息传输过程的安全性。

实施例七

前述图4所示的实施例中,为了确保coresight270的安全,对coresight270进行了审核,以确保coresight270没有被篡改。本实施例进一步提供一种跟踪器的安全实现方法,通过硬件或软件的方式实现安全的跟踪器之后,对跟踪器的审核就不是必须的。

第一种为硬件方式,通过硬件隔离保证coresight270的安全性。

在系统启动阶段通过硬件方式划分coresight270到系统高安全区域,例如,如图14所示,在本实施例中,可以通过tzpc(trustzoneprotectioncontroller)将coresight270的各模块划分到安全世界,即tee侧,从而保证只有tee才能访问coresight270,进而避免coresight270被攻击。

tzpc是架构下的标准模块(ip),它提供了把系统中不同硬件模块划分到安全世界(例如tee)或非安全世界(例如ree)的能力。tzpc的功能是:控制其他硬件的访问权限。通过tzpc可以将一些硬件划分为安全硬件或非安全硬件。其中,安全硬件只能由安全世界的操作系统访问,非安全世界的操作系统访问被划分为安全硬件的硬件寄存器会导致错误。

具体的,在硬件制造时将硬件coresight270和硬件tzpc连接,使tzpc有控制coresight270的能力。系统启动时首先初始化tee侧。在初始化过程中,将coresight270通过硬件tzpc划分为安全态可访问,非安全态不可访问。

第二种为软件方式,通过软件访问权限的设置保证coresight270的安全性。把coresight270的管理放到同一个安全级别的更高特权级别,当低特权级别访问coresight270时会先陷入到高特权级别,通过在高特权级别预制的页表限制对coresight270的访问。

具体的,在系统启动阶段通过配置ree侧el2的页表以防止从el0和el1对coresight270的访问,并在el2分别预制一个coresight270可读写寄存器的列表和可能的值的表格。在鉴权程序210执行与信息采集阶段,ree侧内核对coresight270的访问会陷入到el2,el2只允许el1操作预置的寄存器的特定值。通过这种方式一定程度上来自el1和el0的对coresight270的攻击。在此实施例中,虽然在ree侧对coresight270做了保护,但是仍然有必要在tee执行coresight270审核,以进一步确保安全。

需要说明的是,el是exceptionlevel的缩写,是里的概念。在一种方式下,el0可以被理解为用户态,el1被理解为内核态,el2是hypervisor,el3是安全模式。el2可以控制el0和el1对物理内存的访问。上述实施例的意思就是el2配页表,使得el0和el1访问coresight270的寄存器所在的物理内存地址时受到限制。

图15示出了另一种系统,该系统中ree侧被划分为监视器(hypervisor)22和普通操作系统21(或称客户操作系统)。在这种系统中,普通操作系统21即为前述实施例中第一操作系统(参考图1),它访问硬件层的存储器(例如内存和寄存器)时需要经过两阶段映射:第一阶段普通操作系统21利用管理的第一页表将虚拟地址映射为虚拟线性地址;第二阶段hypervisor利用hypervisor管理的第二页表将虚拟线性地址映射为实际的物理地址。在这种系统中,如果hypervisor管理的第二页表没有对某些寄存器的映射,则普通操作系统21无法访问到这些寄存器控制的硬件,而hypervisor自身可以直接通过物理地址访问它们。虚拟机(virtualmachine,vm)和虚拟机监视器(virtualmachinemonitor,vmm)是该系统的一种具体实现,其中普通操作系统21运行在vm中,vmm即为hypervisor。

利用以上机制,通过hypervisor增强coresight270的安全性,具体实现步骤如下:系统启动;启动hypervisor22;hypervisor22建立第二页表221,第二页表中不包括coresight270的硬件寄存器的地址映射,换句话说,任何虚拟线性地址都不能被映射为coresight270的寄存器的地址。之后hypervisor22启动普通操作系统21,建立第一页表211。

类似地,当鉴权程序210被调用之后,触发coresight270进行信息收集。在触发的时候,不是直接触发,而是普通操作系统21调用hypercall,通过hypervisor22启动coresight270。普通操作系统21运行到待保护的代码以外时,调用hypercall,通过hypervisor22关闭coresight270。

通过以上方法将coresight270的调用下移到hypervisor22,从而避免了普通操作系统21任意操作coresight270,提高了coresight270的安全性。

由于一个跟踪器具有多个组件,例如数据收集模块,数据传输模块和数据存储模块,因此在通过软件或硬件方式实现跟踪器的安全性的时候,可以仅将其中关键的一个或多个组件保护起来,例如在前述硬件或软件实现方式中可以仅将用于存储数据的数据存储模块保护起来。通过这种方式,ree侧操作系统或普通操作系统22依然可以控制coresight270的数据收集模块和数据传输模块,但是无法控制数据存储模块,提高灵活性的同时避免ree侧操作系统或普通操作系统22通过向数据存储模块写入伪造的数据进行欺骗。

第三种为软硬结合的方式。考虑到一个跟踪器有多个组件,为了系统软件设计的便利性和降低软件开销,可以把部分组件(例如etm)通过上述软件方式保护,其余组件通过硬件方式保护。其中,etm(embeddedtracemacrocell)是coresight中的一个组件,用于获取处理器核的跟踪信息。

通过上述任意一种方式,可一定程度上避免跟踪器本身被篡改,确保跟踪器本身的安全,在不影响系统安全性的前提下避免审核跟踪器,简化控制流的审计过程。

实施例八

为了进一步防止恶意程序用错误的数据伪造控制流欺骗控制流审计的过程,本实施例增加被审计的要素,提供一种控制流和数据流的联合审计方法.

图16为本实施例提供的一种终端设备的结构示意图.该终端设备包括一个coresight270,该硬件的etm组件使能了viewdata功能。etm是coresight270的一个组件,位于处理器250内部,用于收集控制流信息。viewdata是etm硬件的一个可选功能。如果配置了该功能则etm有能力监控load/store指令从内存中读入或向内存写入的数据的值。使能viewdata功能后,如果被监控的指令为load/store,则收集的信息除控制流信息之外还带有load/store指令读或写的数据的值,这部分信息本实施例称为数据流或数据流信息。

本实施例中的鉴权程序210已经不再是现有技术的鉴权程序,鉴权程序210的多个位置被插入多个coresight触发指令。部分或全部被插入coresight触发指令的位置存在load/store指令。触发指令用于触发coresight270收集控制流信息和数据信息。coresight触发指令可以是一段程序,该程序的功能是:1.配置coresight270的数据传递寄存器;2.使coresight270开始进行数据收集。其中,功能1中包括配置coresight270的etm组件的寄存器,使能viewdata监控数据流的功能。当审计模块240接收到触发信息之后,从存储器260中获取鉴权程序210的控制流信息和数据流信息,或调用控制流管理模块230获取控制流信息和数据流信息。

前述实施例中提到过自动机的状态具有“初始”和“终止”两种属性,本实施例中在设计自动机时,为每种状态都增加“数据流审计”属性,或者根据需求为其中的一种或多种状态增加这两个属性。含有数据流审计属性的状态同时需要有一个数据约束条件。数据约束条件可以为对一个数据值的范围的限制,如本数据不为0或大于1000等,也可以为和其他数据的关系,如本数据是状态x获得数据的2倍或小于状态y获得的数据等。如果数据约束条件为和其他数据的关系,则自动机同时需要增加一组变量,用来存储自动机运行过程中获取的数据,称为”已获取数据列表”。

另外,本实施例中,设计自动机时,增加一个状态。该新增的状态不是初始和终止状态,且没有任何其他状态的目的状态为该状态。该状态可接受所有事件,且目的状态全部为该状态自身。下文将这个状态称为状态f。

审计模块240被触发后,生成自动机实例并根据获取的控制流信息和数据流信息驱动自动机实例进行状态变换以审计控制流和数据流。本实施例中状态变换规则发生以下变更:接收到待审计信息且状态被推进之后,根据当前状态的数据流审计属性确定是否获取待审计信息中的数据流相关的数据的值(待审计信息中也可能没有数据流相关的数据),根据该状态对应的数据约束条件检查该数据的值。如果通过检查,则将数据保存在自动机的“已获取数据列表”中,继续获取下一条待审计信息;如果未通过检查,将当前状态置为状态f。

具体的,参考图17,获取当前状态s[current]的数据流审计属性的属性值(s1704),若该值不为1,则返回步骤s1701,若该值为1,则比较该数据的值与s[current]的数据约束条件(s1707),若该数据的值满足数据约束条件,则将该数据的值保存到“已获取数据列表”中(s1709),并返回到步骤s1701;否则将s[current]设置为状态f。所有待审计信息都处理完成之后,若s[current]不为终止状态,则审计失败。如果在前面处理时曾有一次s[current]被设置为状态f,根据状态f的特点,状态f将保持到最后,所以会导致审计失败。若s[current]为终止状态,则审计成功,或参考前述任意实施例进行其他的判断。

在其他实施例中,若已知每种数据约束条件均不涉及与其他数据或历史数据比较,则数据流里的数据可以不被记录,即不设置变量“已获取数据列表”。

需要说明的是,这里数据流审计属性的设置仅为举例,其他方式不一一列举。图17仅为本实施例重要步骤的图示,有些步骤与前述实施例类似,可参考前述描述。

本实施例的方法和本申请其他实施例的方法也可以融合在一起使用。例如,数据流审计属性和前述实施例中提到的数据传输属性、随机数发生器访问次数属性其中的一个或多个同时存在,则在处理一条待审计信息时,同时存在的属性按照前述实施例描述的方式进行处理。

实施例九

本申请提供的方法不仅可以应用于相对复杂的场景,也可以应用于简单的场景。针对简单场景,本实施例提供一种简化的审计方法。

本实施例中,只有一个cpu,且在鉴权程序210的执行过程中(下述称为鉴权流程)关闭外部中断。在本实施例中,把鉴权程序210中鉴权流程开始的指令和调用tee功能的指令的地址(分别称为地址a和地址b)硬编码到tee侧的操作系统中。

在本实施例中,不在鉴权程序210中插入coresight触发指令。coresight270由tee侧的操作系统控制,在每次切换进ree之前开启(包括启动时第一次切换进ree)。开启之后coresight270就开始收集控制流信息并存储在其内部的存储器中。切换进tee之时或之后,tee侧的操作系统将存储在coresight270内部的存储器中的控制流信息读取,根据tee侧存储的地址a和地址b(通过上述硬编码获得),找到最后一次出现地址b的采集点y(或理解为数据点),并找出在最后一次出现地址b之前最后一次出现地址a的采集点x。在采集点y到硬件中记录的最后一个采集点之间,检查是否存在其他的采集点,其地址信息为地址a。如果满足以下情况中的任意一个或多个,则审计不通过:1.无法定位采集点;y2.无法定位采集点;x3.在采集点y到硬件中记录的最后一个采集点之间存在地址a。

需要说明的是,在其它实现方式中,依然可以通过在地址a和地址b对应的代码位置插入coresight触发指令来收集控制流信息。另外,上述步骤可以简单地扩展到验证ree是否按顺序执行了3个或更多个地址。

通过上述简化的审计方法,可以看出,审计规则不一定非要通过自动机的方式实现,并通过自动机实例来审计控制流或其他信息,针对不同的场景可以设置不同的规则,根据规则的特点和复杂程度采取不同的实现方式,可能就是根据简单的规则执行简单的匹配过程,同样可以达到审计效果。

实施例十

在前述一些实施例中,原始的程序中被插入跟踪器触发指令形成待保护的程序,这个待保护的程序可以是人工编写的,即触发指令是人工插入的,也可以是计算机根据审计需求自动生成的。本实施例提供一种自动生成待保护的程序的方法。

参考图18,在服务器300侧存在版本生成装置310和版本发布装置320,两个装置可以存在于同一台物理服务器上,也可以存在于不同的物理服务器上。

版本生成装置310中包含加工单元311,该加工单元311用于根据程序和审计需求自动生成待保护的程序和审计规则,并通过位于版本发放装置中的软件发放单元321将生成的待保护的程序,或者待保护的程序和审计规则,发送到终端设备上,例如智能手机、平板电脑等。终端设备将该待保护的程序和审计规则存储在本地的存储器中,可以存储在只读存储区,以避免被恶意篡改。

实施例十一

在待审计控制流中路径较多,审计规则描述复杂时,一方面可能导致审计的效率低下进而影响正常业务,另一方面规则复杂还会导致审计准确性降低从而使得审计失效。针对更加复杂的场景,本实施例提出机器学习的方式来提升审计规则描述的准确性,并尽可能降低规则的复杂度,从而提升审计的效率。

本实施例主要是通过执行采集生成正样本,以及模拟攻击生成负样本,从这两类样本中学习与生成控制流模型,根据这个控制流模型来生成审计规则。在本实施例中,审计规则是机器学习获得的模型,采集到的信息可以直接或经过筛选后输入到该模型中,根据计算后的结果确定是否审计成功(自动机不是必须的)。

另外,不再需要使用插入触发指令的方式来触发跟踪器采集,只要跟踪器被配置为开启状态,跟踪器可以对运行程序的全部控制流信息做采集,通过采集到的控制流信息和机器学习提取审计规则。进一步的,如果想应用前述一些实施例提到的数据流审计等方法,也可以一并采集数据流信息以及其他待审计信息。

如图19所示,该服务器400包括机器学习装置410和规则发放装置420。其中机器学习装置410用于通过机器学习的方法生成审计规则,规则发放装置420中的规则发放单元421用于将该审计规则发送到各个终端设备上。图19的装置420可以和图18的装置320合并为一个装置。

审计规则的生成方法如下:

1、将程序编译成可运行的目标程序,运行模块411在目标终端或者模拟环境中运行该目标程序;2、目标程序运行过程中,运行模块411模拟各种输入条件,采集模块413采集这些条件下的控制流信息和/或数据流信息,作为正样本;3、在目标程序运行过程中,攻击模块412模拟各种可能的攻击,采集模块413采集攻击过程中的控制流信息和/或数据流信息,作为负样本;4、将正负样本作为该程序的特征模型,输入到机器学习算法中,通过该算法提取程序执行特征的规则;5、使得加工工具处理前述规则与待审计源;7、将加工输出的审计蓝本与保护对象,作为版本发布目标置于版本发布服务器。本实施例中的采集模块413是通过跟踪器来采集信息的。

下面介绍正、负样本及学习训练的详细过程。应理解的是,正、负样本的采集过程和前述实施例中描述的审计方法的信息采集过程是类似的。相似或相同部分可参考前述实施例。

(一)正样本的获取

1)到达审计点,提交待审计信息,该待审计信息可以包括控制流信息和数据流信息;

2)安全域(例如tee)操作系统读取循环缓冲区中的待审计信息,并将其记录在(非易失)存储器中,该条记录称为一个正样本;

3)安全域操作系统返回审计通过,并进行后续操作;

4)在不同场景下运行上述过程,获得一定数量的正样本。

循环缓冲去可以实现为一个数组,从头开始记录信息。如果该数组满了,就从头开始继续记录,覆盖掉缓冲区里最早的记录。

(一)负样本的获取

1)对系统进行攻击,尝试绕过该程序并调用审计点,以rop攻击为例:

a.分析系统镜像,使用ropgadget或类似工具找出可用gadget,并构造出攻击链。攻击链实现的功能包括:调用安全操作系统中的某个功能(例如某个ta)。

b.通过有意设置的或者系统中现存的栈溢出漏洞将gadget调用链置于栈上;

c.当系统运行到ret指令时,rop攻击开始:通过rop的方式执行程序中特定的功能,调用安全域操作系统;

2)安全域操作系统被调用即到达审计点,读取循环缓冲区中的待审计信息,并将其记录在存储器中,该条记录称为一个负样本。

rop全称为return-orientedprogramming(面向返回的编程)是一种新型的基于代码复用技术的攻击,攻击者从已有的库或可执行文件中提取指令片段,构建恶意代码。

(三)模型的建立

利用机器学习算法,根据正样本和负样本建立一个分类器。以c5.0决策树算法为例:

1)数据预处理一:解析所有正负样本,为每一个样本生成一个事件集合。其中,事件指样本中出现的事件,如:cpu3执行了位于0xfffffff12340000位置的指令。

2)数据预处理二:消除事件集合中不重要的信息,如cpu编号等。

3)分析正负样本中出现的所有数据点,建立一个高维空间。其中每个曾经在某个样本中出现的数据点为一个维度。如:某个样本中出现了以下信息:执行了位于0xfffffff12340000位置的指令,则高维空间中存在一个维度与之对应。

4)向量化:将每个样本转化为一个在上一步定义的高维空间中的向量。转化的原则是:如果该样本的事件集合中存在一个事件,则向量在该事件对应的维度上值为1,否则值为0。

5)标注:将所有向量化后的样本转化为二元组:<向量,正负>.其中,正样本中“正负”值为true,负样本相反.

6)对上一步中产生的所有标注后的向量使用c5.0算法生成决策树。决策树的效果是:给定一个向量,给出true或false。训练的目标是:尽量让正样本中的向量返回true,负样本中的向量返回false。

7)将上一步产生的决策树编码,得到审计规则。

以下面计算a+b/c的程序为例。该程序转化为汇编语言为:

1:x1=[b]

2:x2=[c]

3:x3=x1/x2

4:x4=[a]

5:x5=x4+x3

这里指令1,2,4都产生了数据。训练时,使用各种合法的a、b和c作为输入,运行上述程序,生成多个正样本。这些正样本的控制流都是1-2-3-4-5,数据流则各相不同,但是c的值从来不为0。

1)首先攻击这段程序。采用各种攻击方法,例如通过rop切入,只执行后续部分;给它发中断打断执行等;使用非法数据,如使c为0等。最终生成多个负样本。2)然后提取特征。这一步需要通过一些数学的方法或经人为指定获得。本示例提取控制流特征:指令1后面跟着指令2,指令2后面跟着指令3,指令3后面跟着指令4,指令4后面跟着指令5(前面都是合法的特征),指令2后面跟着指令1,指令5后面跟着指令2…(这些是非法的特征),以及数据流特征:a不为0,b不为0,c不为0…。3)接下来向量化。将每个数据转化为一个向量。其中,向量的每个维度对应上述的一个特征。如果该数据满足这个特征,则该维度上的值为1,否则为0。例如,一个正样本,其特征可能为[1,1,1,1,0,0,…,0,0,1];一个负样本,其特征可能为[0,1,0,1,0,0,…,0,1,1]。

对每个样本都做以上转换,则会生成多个向量,且知道向量对应正样本或负样本。

得到以上信息,就可以用c5.0决策树训练算法进行训练。最终得到一个决策树,决策树就是审计规则。

在终端设备审计过程中将采集到的信息如上所述向量化以后输入给该决策树,输出该样本为正样本或该样本为负样本,如果结论为负样本则审计不通过。

通过上述机器学习的方式可以自动生成审计规则,并发送到终端设备上,该审计规则可以是一个或多个模型(可理解为公式),然后终端设备实时采集待审计信息,输入该模型,得到审计结果。可见,采用该方法,可以提升审计规则的生成速度和准确性,进而提升审计过程的可靠性。

如果在审计规则生成过程中利用的是全部的控制流等待审计信息,那在终端设备执行控制流审计的过程中也无需再像前述实施例那样插入coresight触发指令,在待保护程序的特定位置去触发跟踪器收集待审计信息,而是在待保护程序开始执行之前能够打开跟踪器,并配置其功能使其能够收集控制流等待审计信息即可。

在其他实施例中,通过机器学习算法也可以把要插入触发指令的位置确定出来,比如说生成决策树以后把权重大的指令挑出来,在这些指令对应的代码处插入触发指令。可见,机器学习算法也可以和触发指令的插入方法结合。

实施例十二

图20为本实施例提供的一种计算机系统的结构示意图。该计算机系统可以为终端设备。如图所示,该计算机系统包括通信模块510、传感器520、用户输入模块530、输出模块540、处理器550、音视频输入模块560、跟踪器570、存储器580以及电源590。

通信模块510可以包括至少一个能使该计算机系统与通信系统或其他计算机系统之间进行通信的模块。例如,通信模块510可以包括有线网络接口,广播接收模块、移动通信模块、无线因特网模块、局域通信模块和位置(或定位)信息模块等其中的一个或多个。这多种模块均在现有技术中有多种实现,本申请不一一描述。

传感器520可以感测系统的当前状态,诸如打开/闭合状态、位置、与用户是否有接触、方向、和加速/减速,并且传感器520可以生成用于控制系统的操作的感测信号。

用户输入模块530,用于接收输入的数字信息、字符信息或接触式触摸操作/非接触式手势,以及接收与系统的用户设置以及功能控制有关的信号输入等。用户输入模块530包括触控面板和/或其他输入设备。

输出模块540包括显示面板,用于显示由用户输入的信息、提供给用户的信息或系统的各种菜单界面等。可选的,可以采用液晶显示器(liquidcrystaldisplay,lcd)或有机发光二极管(organiclight-emittingdiode,oled)等形式来配置显示面板。在其他一些实施例中,触控面板可覆盖显示面板上,形成触摸显示屏。另外,输出模块540还可以包括音频输出模块、告警器以及触觉模块等。

音视频输入模块560,用于输入音频信号或视频信号。音视频输入模块560可以包括摄像头和麦克风。

电源590可以在处理器550的控制下接收外部电力和内部电力,并且提供系统的各个组件的操作所需的电力。

处理器550可以包括一个或多个处理器,例如,处理器150可以包括一个或多个中央处理器,或者包括一个中央处理器和一个图形处理器。当处理器150包括多个处理器时,这多个处理器可以集成在同一块芯片上,也可以各自为独立的芯片。一个处理器可以包括一个或多个物理核,其中物理核为最小的处理模块。

跟踪器570用于采集处理器的指令信息,用于调试或其他用途。跟踪器570包含多个组件,分布在系统的各个层次中,有些组件也可能如图所示嵌入到处理器中。

存储器580存储计算机程序,该计算机程序包括操作系统程序582和应用程序581等。典型的操作系统如微软公司的windows,苹果公司的macos等用于台式机或笔记本的系统,又如谷歌公司开发的基于的安卓系统等用于移动终端的系统。

存储器580可以是以下类型中的一种或多种:闪速(flash)存储器、硬盘类型存储器、微型多媒体卡型存储器、卡式存储器(例如sd或xd存储器)、随机存取存储器(randomaccessmemory,ram)、静态随机存取存储器(staticram,sram)、只读存储器(readonlymemory,rom)、电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory,eeprom)、可编程只读存储器(programmablerom,prom)、磁存储器、磁盘或光盘。在其他一些实施例中,存储器580也可以是因特网上的网络存储设备,系统可以对在因特网上的存储器580执行更新或读取等操作。

处理器550用于读取存储器580中的计算机程序,然后执行计算机程序定义的方法,例如处理器550读取操作系统程序582从而在该系统运行操作系统以及实现操作系统的各种功能,或读取一种或多种应用程序581,从而在该系统上运行应用。

存储器580还存储有除计算机程序之外的其他数据583,例如本申请提出的待审计信息等。

本申请提供的方案中除跟踪器实现的操作之外的其他操作可用硬件或软件来实现。在硬件实现方式下,可以使用专用集成电路(applicationspecificintegratedcircuit,asic)、数字信号处理器(digitalsignalprocessor,dsp)、可编程逻辑器件(programmablelogicdevice,pld)、现场可编程门阵列(fieldprogrammablegatearray,fpga)、处理器、控制器、微控制器和/或微处理器等电子单元中的至少一个来实现本申请的实施方式。在软件实现方式下,诸如过程和功能的实施方式可以使用执行至少一个功能和操作的软件模块实现。软件模块可以以任意适当的软件语言编写的软件程序来实现。软件程序可以存储在存储器580中,并由处理器550读取并执行。本申请中利用的跟踪器包含多个硬件组件,分布在系统多个层次中,但是硬件的执行往往需要软件驱动,所以“跟踪器”中也不排除可以有部分组件是软件实现。

图20中各个模块的连接关系仅为一种示例,本申请任意实施例提供的方法也可以应用在其它连接方式的终端设备中,例如所有模块通过总线连接。

需要说明的是,前述实施例中提出模块或单元的划分仅作为一种示例性的示出,所描述的各个模块的功能仅是举例说明,本申请并不以此为限。本领域普通技术人员可以根据需求合并其中两个或更多模块的功能,或者将一个模块的功能拆分从而获得更多更细粒度的模块,以及其他变形方式。

以上描述的各个实施例之间相同或相似的部分可相互参考。

以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外,本发明提供的装置实施例附图中,模块之间的连接关系表示它们之间具有通信连接,具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

以上所述,仅为本申请的一些具体实施方式,但本申请的保护范围并不局限于此。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1