涉及硬件及其认证方法，更特定来讲涉及认证半导体芯片、电子装置等硬件装置是否为正品、是否发生变造或损伤等的方法。
背景技术：
：对基于软件安全技术来讲，每次发生利用操作系统(operationsystem：os)等的漏洞的新的攻击时需要持续地对此进行安全更新。因此为了防止安全攻击而提出了硬件模块层面的安全攻击防止设计及运用。这种硬件模块层面的安全方法有arm公司的信任区(trustzone)技术。信任区技术之类的基于硬件安全技术是在启动步骤验证os映像的无缺性后读取，因此能够从系统开始步骤起逐步(stepbystep)保障平台的无缺性。这是硬件验证包括os在内的软件的无缺性的方式。而并不是从软件的角度验证硬件的无缺性。美国授权专利公报us8,468,342号(公告日期2013年6月18日)公开了系统启动时确认os无缺性以执行安全启动的运算装置。技术文献″armsecuritytechnology：buildingasecuresystemusingtechnology″(armlimited，white-paperprd29-genc-009492c，april2009)公开了arm公司的信任区(trustzone)硬件结构及在其应用方面的安全启动(securebooting)等。技术实现要素：技术问题本发明的目的是提供一种用于认证硬件装置的硬件装置及其认证方法。技术方案根据一个方面，提供一种半导体芯片，包括：处理器内核；以及与外部信赖机构执行相互认证以执行所述半导体芯片及所述外部信赖机构之间的认证的认证部。根据一个实施例，半导体芯片还包括：第一组，其包括通过第一总线连接于所述处理器内核的元件；以及第二组，其包括通过第二总线连接于所述处理器内核且在安全模式工作的元件。该情况下，只在所述认证部的所述认证成功的情况下才激活使得可用所述第二组。作为例示，但并非限定，所述第二组包括加密ip、安全sram，安全dma及引导rom中至少一个。根据一个实施例，半导体芯片还可以包括：puf，其提供用于所述认证部与外部信赖机构执行所述相互认证的密钥。根据一个实施例，所述第二组利用与所述第一组不同的存储器地址处理数据。作为例示，但并非限定，所述处理器内核包括：core-a处理器，其是32比特risc(reducedinstructionsetcomputing)型的嵌入式处理器。在该实施例中，所述第二总线包括将所述core-a处理器的asr用作控制包含于第二组的元件的地址空间实现的隐藏总线(hiddenbus)。该情况下，所述第二组在所述安全模式可以将作为对所述asr的数据处理指令的mta(movetoasr)指令与mfa(movefromasr)指令用于安全指令(secureinstruction)处理。可以将其理解为利用asr接口构成用于包含于所述第二组的安全ip的隐藏总线。根据另一实施例，所述处理器内核还可以是适用riscvisa的cpu内核。根据一个实施例，所述认证部是硬件逻辑，通过不同于现有的运算语言的专用语言驱动执行所述认证的步骤。并且，所述认证部可执行通过不同于现有的运算语言的专用语言构成的认证步骤。根据一个实施例，所述认证部不同于rom或所述半导体芯片内的ip而由一般单元构成，pnr(placeandroute)时不会泄露到外部或受到安全攻击。根据另一方面，提供一种装置，是嵌入了软件的硬件装置，包括处理器内核，其驱动所述软件；以及认证部，其为了通过所述硬件装置驱动所述软件而与外部信赖机构执行相互认证以执行半导体芯片及所述外部信赖机构之间的认证。根据一个实施例，所述装置还可以包括：第一总线，其将包括在一般模式工作的元件的第一组连接到所述处理器内核；以及第二总线，其将包括在安全模式工作的元件的第二组连接到所述处理器内核。根据一个实施例，只在所述认证部的所述认证成功的情况下才激活使得接入第二总线以使得能够使用所述第二组。根据一个实施例，所述装置还可以包括：puf，其提供用于所述认证部与所述外部信赖机构执行所述相互认证的密钥。根据又一方面，提供一种方法，是半导体芯片的工作方法，包括：认证部与外部信赖机构执行相互认证的步骤；以及只有在所述认证成功的情况下才激活所述半导体芯片的安全模式的步骤。此处，所述半导体芯片可包括：第一总线，其将包括在一般模式工作的元件的第一组连接到所述处理器内核；以及第二总线，其将包括在安全模式工作的元件的第二组连接到所述处理器内核。所述方法在所述认证成功的情况下激活所述第二组及所述第二总线，所述认证失败的情况下不激活所述第二组及所述第二总线而激活所述第一组及所述第一总线。根据一个实施例，所述第二组包括加密ip、安全sram，安全dma及引导rom中至少一个。技术效果根据本发明，能够认证硬件装置。附图说明图1是一个实施例的soc装置的框图；图2显示构成一个实施例的soc的结构；图3a至3f是用于说明根据一个实施例执行预认证的过程和协议的示意图；图4是用于说明一个实施例的安全启动(securebooting)的流程的流程图；图5是用于说明一个实施例的puf的构成的概要图；图6显示一个实施例的受到物理攻击时从根源上进行保护的安全soc平台；图7至图8是用于说明根据一个实施例执行安全启动的流程图。具体实施方式以下参照附图对实施例进行详细的说明。但是，权利范围不限制或限定于这些实施例。各附图上的相同的附图标记表示相同的部件。以下说明中使用的术语是选用于相关
技术领域：
通常、普遍的术语，但可随着技术的发达及/或变化、惯例、技术人员的喜好等而有其他术语。因此，以下说明中使用的术语不应被理解为限定技术思想，应理解为用于说明实施例的例示性术语。并且，特定情况下还有申请人任意选定的术语，该情况下会在相应的说明部分记载其具体含义。因此，以下说明中使用的术语并非单纯术语的名称，因此应根据该术语所具有的含义和说明书全文的内容进行理解。硬件与软件的相互认证如上所述，基于硬件的安全技术中硬件通过安全启动之类的步骤验证软件的无缺性的技术很普遍。当发现智能手机或手持设备的os不是无缺的映像，而是受损或由于侵入等导致安全功能发生变造的情况下，硬件在启动步骤发现这些问题，及/或在运行特定应用程序的步骤发现以阻止安全危险等。在安装有被黑客变造的os的智能手机运行手机银行或支付应用程序时验证是否为被侵入的os并停止执行步骤已经很常见。然而反过来用os或应用程序软件认证硬件的技术则没有。像如今无线发布(distributiononair)智能手机的移动os乃至电子装置的固件、嵌入式软件及各种应用程序的情况下，从开发者或制造者立场来讲，保障要安装运行这些的装置为正品且未发生变造/损伤的无缺性是非常有必要的技术。以下公开的多个实施例公开为了防止非法仿造硬件、合约规定的使用期限到期的硬件、为接近原来的设备中被安保拦住的功能、信息而变造的硬件等而由软件自主地认证硬件的技术。当然还包括硬件认证软件的内容，从这种层面来讲，也可以理解为通过硬件与软件的相互认证保障安全性的系统。以下的实施例例示说明在片上系统水平的装置中硬件与软件相互认证的技术，但并非必须局限于此。因此在不脱离发明的思想的范围内还可以有手持装置的硬件与其os或固件的相互认证、甚至汽车或航空器与其运行软件的相互认证等类似的多种应用。对片上系统的软件的安全攻击对soc的攻击包括物理性攻击与软件攻击。如果物理性攻击无力化且软件系统得到安全soc平台的保护，开发者便无需对安全问题费心思，可以专注于自己的事情。此处公开的实施例提供防止对软件的安全攻击以在安全环境运行的soc平台。受到软件攻击时有些情况下仅凭软件模块难以进行防御，因此优选的是从硬件模块层面防御软件安全攻击。作为例示，可以是arm公司的信任区之类的环境。为了利用信任区，需要可信执行环境(trustedexecutionenvironment：tee)标准定义的安全操作系统(operationsystem)或安全库。而tee的性能要求事项是使用小的cpu内核与实时操作系统(realtimeos：rtos)的物联网(internetofthings：iot)的终端soc可能难以满足的水平。根据实施例，公开具有用于替代引起大的额外负担的安全操作系统(secureos)或库的能够直接支持tee的安全指令集架构(instructionsetarchitecture：isa)的soc。并且，公开能够执行这种安全isa的cpu内核及其工作方法的实施例。以下参考附图说明多种实施例。系统的构成图1是一个实施例的半导体片上系统100的框图。芯片包括处理器的内核101。内核101上分别连接有第一总线111与第二总线121。第一总线111提供于作为在一般模式(normalmode)工作的通用运算组的第一组112。可以将‘组’理解为个别运算知识产权(intellectualproperty：ip)或存储器、缓存等的集合。即使以下无其他明确记载，元件、ip、功能要素、运算知识产权等可以混用。第二总线121提供于包括仅在安全模式(securemode)工作的元件的第二组122。第二总线121与第一总线111物理上完全分离。这种物理性孤立可以区分出一般区域(normalworld)110与安全区域(secureworld)120，该区分提供对施加于软件的安全攻击强韧的soc。可以将物理性孤立理解为一般区域110的第一组112用完全不同于安全区域120的第二组122的存储器地址体系处理数据。soc100可包括系统通电时及/或根据需要有必要运行安全模式时与外部认证机构(未示出)对安全区域120执行相互认证的认证部102。认证部102可以对外部认证机构证明soc100、第二组122及其个别ip、内嵌于其中的软件合法无缺以获得认证。并且，认证部102还相互认证是作为当前事务对象的外部终端可信赖的所述外部认证机构。后续将参见图3具体说明认证部102从预认证(pre-authentication)外部认证机构获得公钥登录并获得发给的认证书的发给协议和根据需要将现有的公钥更换为新公钥等软件的硬件认证。一般模式与安全模式的转换一个实施例的soc100可具有一般模式(normalmode)与安全模式(securemode)。第二组122只在上述认证部102的认证成功的情况下才启动，关于可信执行环境(trustedexecutionenvironment：tee)的安全区域120激活。当然，该情况下第一组112也启动，一般区域110激活。而所述认证不成功的情况下，只有关于一般执行环境(richexecutionenvironment，ree)的第一组112启动使得一般区域110激活，但安全区域120不激活。即使在安全区域120激活的情况下，第二组122也未必一直在工作，有可能处于待机状态。由于ree环境的运算，例如安卓操作系统与应用程序运行的过程中发生违反安全事件(eventofsecureviolation)或需要金融结算等原因而发生提高的安全操作需要处理的调用时可执行所述安全模式。换而言之，在一般区域中移动电话的安卓之类的ree(richexecutionenvironment)和一般的硬件ip一起在基于arm的soc工作。在此状态下，需要安全资源，例如需要加密ip(cryptographicip)或安全静态随机存储器(securesram)时由安全操作系统与安全硬件ip构成的tee工作并向ree传送结果。arm公司的信任区向ambaaxi进一步提供作为用于接入soc平台的安全ip的控制信号的1比特总线信号。而使用普通的小cpu内核与实时操作系统(realtimeos：rtos)的物联网(internetofthings：iot)终端soc可能难以满足tee的性能要求事项，而实施例则可以满足这些。认证的手段根据一个实施例，半导体soc100还可以包括提供用于认证部102与所述外部信赖机构进行相互认证的根键(rootkey)的物理不可复制功能(physicalunclonablefunction：puf)103。可在所述认证时使用这种利用根键的rsa、aes等多种认证算法中至少一个。作为例示，但并非限定，puf可利用半导体制造工程上的工程偏差内在地(intrinsic)包含于所述半导体芯片内。根据一个例示性的构成，所述puf可以是根据层间接触于半导体的导电层之间的通路(via)或层间接点在工程中是否正常图案化使所述导电层之间短路提供数字值的构件。后续将参见图5及图6对puf的实现及作用进行更详细的说明。安全存储器根据一个实施例，安全存储器130包括在一般模式下利用的区域和在安全模式下利用的区域。安全存储器130例如包括非易失性存储器(nvm)。在安全模式下利用的区域可利用puf103提供的根键加密存储数据，而并非直接如实存储。因此，即使物理性地提取了安全存储器130的数据，但如果不直接连接(directwired)于puf103解密便无意义。构成例示性的系统-core-a平台的利用图2显示一个实施例的在core-a环境构成soc的结构。作为例示，但并非限定，所述处理器内核包括作为32比特精简指令集计算(reducedinstructionsetcomputing：risc)型的嵌入式处理器的core-a处理器201。根据另一实施例，所述处理器内核还可以是适用riscvisa的cpu内核。在以下记载中，应理解‘处理器’、‘处理器内核’、‘安全内核’、‘安全处理器’等是可以根据情况相互换用的术语。作为例示性的实现方式主要对利用‘core-a’的实现方式进行说明，但也可以构成适用riscvisa的cpu内核等其他类型，这对本领域技术人员而言是显而易见的。一般总线210上连接有作为ree环境的第一组元件的sram211、多个外设ip(peripheralip)212、调试接口213。并且，安全总线220上连接有应在tee环境工作的加密ip(cryptographicip)221、引导rom(bootrom)222、安全sram223及安全dma224。如参见图1所述说明，具有认证部202及至少一个puf203，从而能够进行认证。puf203可直接连接于内核201以用于认证，并且可直接连接于加密ip中aes/seedip、ecc/rsaip。进一步地，安全nvm230也可以直接连接于puf203对数据进行加密以安全存储。一个实施例的安全总线220可以是将所述core-a处理器的应用程序特定寄存器(applicationspecificregister：asr)作为用于控制所述安全区域的第二组元件的地址空间使用而实现的隐藏总线。在该应用中，所述第二组可以在所述安全模式将作为对所述asr的数据处理指令的mta(movetoasr)指令与mfa(movefromasr)指令用于安全指令(secureinstruction)处理。这也可以理解为利用asr接口构成用于所述第二组中包含的安全ip的隐藏总线。根据这种构成，构成替代具有大的额外负担的安全操作系统(secureos)或库的能够直接支持tee的安全指令集架构(instructionsetarchitecture：isa)。因此相比于利用arm的信任区(trustzone)，适合具有小cpu的设备。根据实施例，为了管理区别于一般模式的安全模式、硬件与软件相互认证而提供作为认证部的预认证(pre-authentication)硬件。并且提供利用可靠性、稳定性、随机性已得到验证的via-puf(physicalunclonablefunction)的相互认证硬件ip，因此提供具有强化的安全区域的‘安全soc平台’。根据公开的实施例，公开安全isa。是不同于一般的isa的另外构成的安全区域版本的isa。为了通过现有的arm公司信任区(trustzone)技术的方法接近安全区域内资源，需要安全操作系统或复杂的库。而根据公开的实施例中，可根据安全isa在指令(instruction)层面上直接接接近安全区域内资源。并且，可通过使用预认证ip管理进行对安全isa的安全模式管理，以执行安全的相互认证，拦截未授权的用户接近内部，例如拦截软件攻击。实施例公开的安全内核提供对安全区域的隐藏的通道，其与主存储器接口物理分离。并且使得读取软件时利用安全dma通过硬件自动确认无缺性，内部puf为了认证而提供安全存储空间或用于安全ip的密钥。对此分别进行具体说明。安全isa(instructionsetarchitecture)为了根据现有方法在安全区域内使用资源或调用安全函数，需要用于在通用cpu内核工作的安全操作系统或库。而根据实施例，公开提供安全区域的要求事项和安全操作系统及库的特征性功能的同时没有额外负担的安全isa，其在功能上扩张以往的core-a。其使得安全系统无需安全操作系统或库的帮助或受到应用程序开发的困扰地直接接近信任区，能够减少管理方面的付出。实施例的安全isa的例示特征如下。-控制流无缺性：为了效率而用一个指令替代保护控制流的无缺性的代码-密钥管理：包括生成用于公钥加密的随机数及密钥对-存储器安全等级管理：按各页面与分块提供多种安全等级-安全引擎：扩张与安全硬件引擎密切地工作的isa-安全启动/认证：支持用于安全调试与启动的认证-安全模式管理：支持管理用于安全模式的微结构-寄存器内容保护：用via-puf加密安全寄存器的内容执行预认证(pre-authentication)图3a至3f是用于说明一个实施例的执行预认证的过程和协议的示意图。参见图3a，硬件soc300内具有处理认证且在安全模式工作的部分310。为了使得能够使用安全isa，预认证ip301在电源开或重置之后通过终端之间相互认证与外部认证书服务器，例如在商业网上管理终端安全的终端安全管理(terminalsecuritymanagement：tsm)系统服务器301进行通信。如图例示，但并非限定，这种相互认证可采用利用puf303生成的根键的公钥加密方式。根据一个实施例，用于所述相互认证的预认证ip301内的认证协议不是一般语言(例如，c等高级语言或特定内核用组合)。预认证ip301内由为了仅执行认证协议而设计的专用语言构成，因此难以分析且实质上无法分析。并且，预认证ip301由硬件逻辑构成，因此不仅无法修改(保障无缺性)且通过基本单元的组合构成而并非构成rom等物理分离的ip形态，因此能够使得在局部及路由(placeandroute：pnr)过程中与其他单元混合，因此对反向工程等物理攻击也强韧。服务器301与公开的平台300用各自的个人密钥生成签名，认证书内含有自己的公钥。通过交换认证书与签名执行相互认证。预认证ip302从via-puf303得到个人密钥并将用此生成的签名传递到认证书服务器。并且，用已存储的外部认证书服务器的公钥验证接收的签名。在此，签名算法可以是ecc或rsa之类的公钥加密算法。系统随着相互认证成功进入安全模式时安全内核控制安全启动。并且调试接口仅在安全模式时打开，仅允许经过认证的用户执行调试。认证成功的情况下可允许安全模式，安全区域的ip资源(311及312等)可工作。另外，相互认证时交换的共享密钥在后续为了安全而在交换数据时用作加密密钥或信息认证码(messageauthenticationcode：mac)用密钥及用于加密或mac的起始向量(initialvector：iv)，以用于通信时确保机密性及无缺性。以下说明用于相互认证的具体协议。预认证(pre-authentication)协议预认证协议包括在使用之前注册公钥并获得发给的认证书的‘发给协议’和能够根据需要将现有的公钥更换成新的公钥并重发对新公钥的认证书的‘重发及更新协议’。发给之后芯片从向终端安全管理(terminalsecuritymanagement：tsm)系统发出使用请求开始，还剩有有效期限的情况下在线执行使用协议，有效期限到期的情况下在线执行更新协议。当tsm判断出有效期限到期后过了很长时间或相应芯片的现有密钥对由于攻击等而不再有效的情况下，无法使用线上的使用协议和更新协议，需要发给机构按照与发给协议相似的方式重发。在此，重发协议只省略id发给部分，因此除此之外与发给协议几乎相同。并且，由于由假设安全的发给机构变更密钥与认证书，而且现有密钥不再有效，因此传递公钥时无需签名。换而言之，在更新协议将芯片新生成的公钥传递给tsm时用变更前个人密钥签名并传递。以下参见附图对各步骤的协议进行具体说明。发给协议图3b公开的流程公开发给协议。是注册设备生成的公钥对中的公钥，并获得发给的对公钥的认证书的过程。公钥对的生成及传递、认证书发给部分在重发协议也可以相同地执行。首先执行芯片及序列号目录传递过程。关于有效的设备的序列号目录(sn-list)已由制造者传递到tsm(3202)。插入芯片(3201)：向发给设备插入认证芯片或插入有认证芯片的设备。在此，设为发给者(例如银行或信用卡公司)驱动的发给设备可信。请求sn：此时发给设备向芯片请求获得sn。请求id：发给设备在向tsm请求关于该芯片的id的同时传递从芯片得到的sn。tsm生成id(3203)，确认收到的sn(3204)后将自己的公钥qtsm与id一并传递到发给设备。*错误处理(判断为非有效的sn的情况下)：tsm得到非有效的sn的情况下，所述步骤可以将传递id改为用错误消息err_id响应、废弃(disuse)并结束(3205)。选择性地，发给设备可以再次向芯片请求提供有效的sn，可以从过程起重复。请求公钥：若无错误，发给设备在向芯片请求公钥的同时传递从tsm收到的id、tsm的公钥。*错误处理(crc错误)：发给设备从tsm收到的消息有crc错误的情况下重新请求d(req_id，重复)以重新获得id、tsm的公钥。公钥生成准备：芯片执行crc检查(3206)、tsm的公钥的有效性检查(3207)。并且初始化用于生成公钥的更新信息upnumecc(3208)。*错误处理(crc错误)：芯片从发给设备收到的消息有crc错误的情况下发送错误消息err_puk以重新获得id、tsm的公钥。*错误处理(公钥错误)：芯片从tsm接收的tsm的公钥qtsm非有效的情况下用错误消息err_puk响应以再请求tsm的公钥。发给设备接收其并向tsm请求id(req_id，重复)以重新获取id、tsm的公钥。所述初始化(3208)后在步骤3209执行图3c。参照图3c说明的至是发给与重发的共同部分，在关于发给的图3b中称为步骤3209，在关于重发的图3e中称为步骤3508。下述图3e的步骤3508过程再次参见此处的至公钥生成及传递(3301)：根据id、puf、更新信息生成公钥对并将其中的公钥传递到发给设备，发给设备将其发送到tsm。将该区间视为可信赖，附加crc代码使得能够排除通信上的错误。*错误处理(crc错误)：发给设备从芯片接收的消息发生crc错误时(3302)发送错误消息err_puk以重新获得芯片的公钥。重复错误时可废弃(disuse)芯片(3303)。发给认证书：tsm执行crc检查(3304)、芯片公钥的有效性检查(3305)。并且生成在接收的公钥用自己的个人密钥签名的认证书(3307)并传递到发给设备，发给设备将其传递到芯片。作为参考，图3b至3d示出的认证书仅含有芯片的id与公钥、对其的签名，而必要情况下在签名的对象、认证书内容中除id及芯片的公钥之外还包括发给机构、有效期限等附加信息。*错误处理(crc错误)：tsm从发给设备收到的消息中发生crc错误时发给设备向芯片用crc错误消息err_cert响应请求重新发送。*错误处理(公钥错误)：tsm从发给设备收到的芯片的公钥qchip非有效的情况下用错误消息err_cert响应以再请求芯片的公钥。发给设备收到其后将错误消息err_puk传递到芯片。重复错误时可废弃(disuse)芯片(3306)。*错误处理(crc错误)：发给设备从tsm收到的消息发生crc错误时(3308)发给设备向tsm重新发送认证书请求消息req_cert。验证认证书：芯片检查crc(3309)，确认包含于认证书的id与公钥是否与自己的相同。并且确认关于id与公钥的认证书的签名(3310)。确认签名后将更新信息upnumecc与从tsm获得的认证书存储在非易失性存储器(3313)。*错误处理(crc错误)：芯片从发给设备收到的消息发生crc错误时(3311)芯片用crc错误消息err_reg_cert响应发给设备以请求重新发送。重新发送后如果是错误处理则可废弃(3312)。*错误处理(认证书错误)：认证书错误(id、公钥、签名错误)时芯片向发给设备发送认证书错误消息err_reg_cert，发给设备发送给tsm再请求(req_cert)认证书并重复之后过程。以上为发给与重发的共同的图3c部分，重新回到发给过程即图3b的存储id、qtsm的步骤(3210)之前执行步骤(3210)。发给结束后各芯片将获发的id与初始化的更新信息upnumecc、tsm的公钥qtsm及关于自己的公钥的tsm的认证书(是用tsm的个人密钥签名芯片的公钥的)存储于非易失性存储器。发给后tsm具有关于发给的芯片的sn-id-公钥目录。假设芯片与发给者(发给设备)、tsm、制造社之间的连接安全。即假设攻击者无法介入发给步骤。更新协议发给结束的芯片通电且芯片向tsm发送使用请求时，tsm确认该id的芯片的有效期限的结果为已无有效期限的情况下不许芯片使用，并向芯片请求更新公钥。由于是不安全的通信环境，因此传递新生成的芯片的公钥时用现有的个人密钥(更新前个人密钥)签名后传递以保障是来自该芯片的新公钥。具体的协议将参见图3d进行说明。请求确认有效期限：将id与随机数rn传递给tsm(3401)。确认有效期限及请求更新：tsm确认有效期限(3402)。已无有效期限的情况下请求更新。将id与接收的随机数及用tsm的个人密钥签名更新代码renewal后附加到更新请求消息使得攻击者无法任意更新设备。更新及传递公钥对：芯片确认接收的更新请求消息的id与签名(3403及3404)后，利用增加1的upnumecc新生成公钥对(d′chip、q′chip)(3405)。并且用更新前个人密钥dchip对其中的公钥签名与id一起签名并传递给tsm(3406)。*错误处理(id错误)：若芯片从tsm收到的id不是自己的，则用错误消息err_renewal响应。tsm确认id且如果是正确的便从更新请求消息req_renewal起重复。*错误处理(签名错误)：芯片从tsm接收的签名非有效的情况下，用错误消息err_renewal响应。tsm重新发送现有更新请求消息req_renewal或从生成签名起重复。发给认证书：tsm检查芯片的公钥的有效性且检查签名的有效性(3407至3409)。并且生成在接收的公钥用自己的个人密钥签名的认证书并传递给芯片。如上所述，再生成认证书时也可以除公钥之外还附有附加信息。*错误处理(公钥错误)：tsm从芯片收到的芯片的公钥q′chip非有效的情况下用错误消息err_renewal响应以再请求芯片的公钥。*错误处理(签名错误)：tsm从芯片收到的消息的签名非有效的情况下用错误消息err_renewal响应芯片以请求重新发送。芯片从生成签名起重复。验证认证书：芯片确认包含于认证书的id与公钥是否与自己的相同(3410)。并且确认关于id与公钥的认证书的签名(3411)。确认签名后将upnumecc与从tsm收到的认证书存储在非易失性存储器(3413)。*错误处理(认证书错误)：发生认证书错误(id、公钥、签名错误)时可以废弃(3412)，但芯片也可以向tsm发送认证书错误消息err_reg_cert以再请求认证书重复过程。更新结束后芯片将关于用于更新公钥的增加1的upnumecc与新更新的公钥的tsm的认证书存储在易失性存储器。并且经过步骤3414与步骤3415结束更新协议。重发协议更新时用现有的个人密钥签名新公钥以保障是芯片的新公钥。而有效期限到期后过了很长时间的情况下无法再使用现有的个人密钥，因此需要由发给机构重发芯片，具体协议如下。请求确认有效期限：插入卡(3501)后芯片不知道是否为重发状态，因此像更新一样生成id与随机数rn(3502)并一同与发送的指令传递至发给设备。发给设备接收其后向tsm请求重发指令。请求重发：tsm按照与更新请求近似的方式将id与接收的随机数、以及重发代码issue用tsm的个人密钥签名(3503)后附加到重发请求消息。确认重发请求：芯片确认crc与id、签名后(3504至3506)使upnumecc增加1(3507)。*错误处理(crc错误)：芯片从发给设备收到的消息有crc错误的情况下发送错误消息err_repuk以重新获得id、签名。*错误处理(id错误)：若芯片从tsm收到的id不是自己的，则用错误消息err_repuk响应。tsm确认id并在对的情况下从重发请求消息req_repuk起重复。*错误处理(签名错误)：芯片从tsm收到的签名非有效的情况下用错误消息err_repuk响应。tsm重新发送现有更新请求消息req_repuk或从生成签名起重复。并且，此处重复上述通过图3c说明的发给协议的至(发给的)生成及传递公钥(3301)：根据id、puf、更新信息生成公钥对并将其中的公钥传递到发给设备，发给设备将其传递到tsm。将该区间视为可信赖，并附加crc代码使得能够排除通信上的错误。*错误处理(crc错误)：发给设备从芯片收到的消息发生crc错误时(3302)发送错误消息err_puk以重新接收芯片的公钥。重复错误时可废弃(disuse)芯片(3303)。(发给的)发给认证书：tsm执行crc检查(3304)、芯片的公钥的有效性检查(3305)。并且用自己的个人密钥在接收的公钥签名生成认证书(3307)传递到发给设备，发给设备将其传递到芯片。该情况下也可以像发给时一样根据必要附加多种附加信息(即，发给机构、有效期限)。*错误处理(crc错误)：tsm从发给设备收到的消息发生crc错误时发给设备向芯片用crc错误消息err_cert响应以请求重新发送。*错误处理(公钥错误)：tsm从发给设备收到的芯片的公钥qchip非有效的情况下用错误消息err_cert响应以再请求芯片的公钥。发给设备接收其并将错误消息err_puk传递到芯片。重复错误时可废弃(disuse)芯片(3306)。*错误处理(crc错误)：发给设备从tsm收到的消息发生crc错误时(3308)发给设备向tsm重新发送认证书请求消息req_cert。(发给的)验证认证书：芯片检查crc(3309)并确认包含于认证书的id与公钥是否与自己的相同。并且确认关于id与公钥的认证书的签名(3310)。确认签名后将upnumecc与从tsm收到的新认证书存储到非易失性存储器(3313)。*错误处理(crc错误)：芯片从发给设备收到的消息发生crc错误时(3311)芯片向发给设备用crc错误消息err_reg_cert响应以请求重新发送。重新发送后为错误处理时可废弃(3312)。*错误处理(认证书错误)：发送认证书错误(id、公钥、签名错误)时芯片将认证书错误消息err_reg_cert发送给发给设备且发给设备发送给tsm以再请求req_cert认证书，之后在步骤3508执行图3c说明的内容。这是参见图3c说明的发给过程的至执行该部分后再回到图3e的收尾步骤。重发结果为新存储增加1的upnumecc与新获发的认证书r′、s′(3507)。与发给协议一样假设攻击者无法介入发给步骤。使用协议参见图3f进行说明。使用协议是与tsm执行相互认证使内核赋予安全模式的权限的协议。是执行图3a说明的认证过程的例示性协议。请求确认有效期限：与更新、重发协议一样生成id与随机数rn(3601)并传递给tsm且协议开始。确认有效期限及请求会话：tsm确认有效期限(3602)。还剩有有效期限的情况下通过用于共享芯片与密钥的密钥交换协议(ecdh)过程生成临时密钥对a、a。并且用tsm的个人密钥对其签名并传递给芯片。生成共享密钥：芯片确认接收的id(3603)，确认接收的公钥a的有效性及签名的有效性(3604及3605)。并且通过ecdh过程生成芯片的临时密钥对b、b。并且利用从tsm收到的临时公钥a与芯片生成的临时个人密钥b形成共享保密信息w，并用密钥诱导函数(keyderivationfunction)对其进行扩张生成共享密钥k1、k2、iv(3606)。生成的公钥与对此用芯片的个人密钥签名的签名，并且为了握手(handshake)而将用共享密钥加密的信息c1传递给tsm(3607至3608)。*错误处理(id错误)：若芯片从tsm收到的id不是自己的，则用错误消息err_sessio响应。tsm确认id且在对的情况下从会话请求消息req_session起重复。*错误处理(公钥错误)：芯片从tsm收到的公钥非有效的情况下用错误消息err_session响应。tsm从会话请求消息req_session起重复。*错误处理(签名错误)：芯片从tsm收到的签名非有效的情况下用错误消息err_session响应。tsm重新生成签名或从会话请求消息req_session起重复。握手：tsm确认接收的公钥b的有效性与签名的有效性(3609及3610)。并且利用接收的芯片的公钥b与tsm生成的临时个人密钥a形成共享保密信息w，并用密钥诱导函数(keyderivationfunction)对此进行扩张生成共享密钥k1、k2、iv(3611)。利用其解密c1以确认芯片生成了相同的共享密钥。tsm也将用共享密钥加密的信息c2传递给芯片(3612)。*错误处理(公钥错误)：tsm从芯片收到的公钥非有效的情况下用错误消息err_hs响应。芯片从握手请求消息req_hs起重复。*错误处理(签名错误)：tsm从芯片收到的签名非有效的情况下用错误消息err_hs响应。芯片重新生成签名或从握手请求消息req_session起重复。如果签名错误重复的情况下停止握手过程并一并发送用于认证失败的错误消息err_hs与认证失败代码er_auth使得将认证结果设为失败(fauth＝fasle)。*错误处理(握手错误)：tsm从芯片收到的c1的确认结果为失败的情况下用错误消息err_hs响应。生成密钥或从生成c1起重新执行。握手2：芯片解密接收的c2并进行确认以确认tsm也生成了相同的共享密钥(3613)。*错误处理(握手错误)：芯片从tsm收到的c2的确认结果为失败的情况下用错误消息err_hs响应。生成共享密钥或从生成c2起重新执行。可通过以上过程中彼此收发的签名相互认证彼此，共享的密钥k1、k2、iv在后续与tsm通信时分别用作加密密钥、mac用密钥、起始向量(initialvector)。认证成功执行的情况下赋予对安全模式的权限(fauth＝true)(3614)。以上分别是预认证的执行、发给、更新、重发、使用的具体协议。预认证认证部通过这种过程认证装置与tsm等硬件。硬件的软件认证现有的trustzone等tee(trustedexecutionenvironment)为了保障平台的无缺性而包括安全启动功能。其用于防止系统在os映像本身受到污染的状态下开始，是启动时确认os映像的无缺性后运行使得平台能够在无缺的状态下开始的技术。图4是用于说明一个实施例的这种安全启动的流程的流程图。设备通电(410)后，rom的soc引导加载程序420最先运行获得权限。引导加载程序(bootloader)存储于on-socrom，无法修改，因此作为可信根(rootoftrust)成为安全启动步骤的基础。并且on-soc硬件具有无法修改tsm认证机构的公钥的otp形态等。引导加载程序420利用该公钥验证来自闪速设备引导加载程序(flashdevicebootloader)430的签名以确认无缺，之后对闪速设备引导加载程序430赋予权限使得能够运行。得到权限的闪速设备引导加载程序430验证安全区域os的映像的签名以确认无缺并使其运行(安全启动)440。在后续也重复这种过程使一般区域引导加载程序450获得权限启动一般区域os(460)，系统驱动。由于无法修改而保障无缺性的硬件层面的可信根起逐步执行软件认证的同时前进的这种过程被称为信任链。硬件通过这种方式用信任链认证要在硬件执行的软件，如参考图3a至3f所述说明，软件也认证硬件以执行相互认证。利用puf强化安全实施例的puf(physicalunclonablefunction)可利用半导体制造过程中发生的工程偏差生成芯片固有的真随机比特(truerandombit)。半导体制造过程中发生的每个芯片的工程偏差各异，因此大量生产芯片时puf可用作芯片的固有id，利用其的情况下可提供用于加密/解密、保护存储器、电子签名等的根键(rootkey)。这种puf的值不容易泄露到芯片外部，因此作为可信根(root-of-trust)可提供最上位安全等级。当前洲际弹道导弹(icbm)等军用武器、车辆用安全系统(hsm)、智能手机的ap、智能卡等多种应用领域正在进行为了将puf用于安全的标准化及商用化。图5是用于说明一个实施例的puf的实现的概要图。需注意这只是例示构成，并不局限于此。根据一个实施例，puf具有设计小于一般设计规则(图示的例中是250nm*250nm)规定的通路孔尺寸(viaholesize)的通路孔制成的通路(或层间接触)阵列。该情况下，在通路孔阵列中，开路(open)和短路(short)随机(random)分布，其可提供随机(random)且实质上时间不变(invariantovertime)的数字值(digitalvalue)。根据公开的实施例制造的viapuf通过了公认评价机构的基于jedec标准的多种测试，可靠性(reliability)得到了验证，随机性也通过了作为nist标准的sp800-90b的真随机数测试包(truerandomnumbertestingsuite)。增加的实施例的说明图6显示一个实施例的受到物理攻击时从根源上进行保护的安全soc平台。除连接于安全内核601执行ree环境的运算的一般总线610之外提供用于安全区域的隐藏总线620。sram611或外设ip(peripheralip)612在一般模式下工作的过程中需要运行安全模式的情况下，可通过安全isa在指令级别运行安全ip621。根据一个实施例，安全内核601将存储器区域分割成代码区域与数据区域。被分割的存储器区域可以是一般区域的，而根据其他实施例，也可以是安全区域的。安全内核601可包括禁止在所述代码区域写入(write)，禁止在数据区域运行(execution)的存储器保护单元(memoryprotectionunit：mpu)。此处，可通过利用对所述core-a处理器的asr的指令处理的安全指令设置所述代码区域与所述数据区域。进一步地，除了所述代码区域与所述数据区域之外还可以设置系统区域。[表1]区域\模式u/nu/sp/np/s代码区域rxrxrwxrwx数据区域rwrwrwrw系统区域--rwxrwx上表中，模式″u″表示用户模式(usermode)，″p″表示权限模式(privilegemode)。并且″n″表示一般模式，″s″表示安全模式。公开了各代码区域允许的工作。例如，是用户模式且一般模式时可以进行r即读取、x即运行(execution)，但不允许w即写入。另外，根据一个实施例，所述处理器内核可包括备份包含于代码序列的返回地址的基于硬件影子堆栈。该情况下，所述影子堆栈可独立于常驻在现有的存储器上的堆栈位于相同或另加的存储器或另加的寄存器等。所述影子堆栈不使用总线，不被操作系统或软件接近，可通过增加的基于硬件控制电路执行存储器堆栈相关指令时自动执行以双重管理所述返回地址。通过双重管理利用影子堆栈的返回地址，能够感测软件攻击导致的常驻于现有的存储器上的堆栈中存储的返回地址变更。影子堆栈仅受硬件电路控制，无法通过软件接近，因此能够从根源上切断欲变更存储于影子堆栈的内容的攻击。以上说明的影子堆栈是双重管理返回地址的例示性构成，只要是周期性地备份返回地址进行双重管理的堆栈便不受特定例示构成的限制。系统启动时的工作图7至图8是用于说明一个实施例的soc的工作的流程图。根据一个实施例，设备通电时执行从认证书服务器获得认证的步骤(710)。此处，作为基于硬件认证部的预认证ip(pre-authenticationip)通过终端之间相互认证与外部认证书服务器通信的内容如通过图3a所述说明，该过程中利用puf的内容已参见图5进行了说明。在步骤720认证成功的情况下，管理使得能够使用安全isa(730)，能够接近调试接口，安全区域操作系统启动(740)。并且之后通过启动一般模式使得系统可驱动(750)。而在步骤720认证失败的情况下，图8的步骤810无法接近安全区域。并且只有一般区域启动，只能驱动ree环境的运算。这种过程如参见图1、图2及图4等所述内容。以上说明的装置可以由存储器的硬件构成要素、控制存储器的软件构成要素及/或硬件构成要素及软件构成要素的组合实现。例如，实施例中说明的装置及构成要素可以由例如处理器、控制器、算术逻辑单元(arithmeticlogicunit；alu)、数字信号处理器(digitalsignalprocessor)、微型计算机、现场可编程阵列(fieldprogrammablearray；fpa)、可编程逻辑单元(programmablelogicunit；plu)、微处理器或能够运行和响应指令(instruction)的其他任意装置之类的一个以上的通用计算机或特殊目的计算机实现。软件可包括计算机程序(computerprogram)、代码(code)、指令(instruction)或其中一个以上的组合，可构成处理装置使得按要求工作，或独立或结合起来(collectively)命令处理装置。关于软件及/或数据，为了通过处理装置解析或向处理装置提供指令或数据，可永久或临时具体化(embody)于某种类型的机器、构成要素(component)、物理装置、虚拟装置(virtualequipment)、计算机存储介质或装置或传输的信号波(signalwave)。软件分散于通过网络连接的计算机系统上，可通过分散的方法存储或运行。软件及数据可存储于一个以上的计算机可读存储介质。实施例的存储器工作控制方法可以构成为能够通过多种计算机机构执行的程序指令形态并存储在计算机可读存储介质。所述计算机可读存储介质可包括程序指令、数据文件、数据结构等中的一个或组合。存储在所述介质的程序指令可以是为实施例而特别设计和构成的程序指令或计算机软件相关技术人员可公知使用的程序指令。计算机可读存储介质例如包括硬盘、软盘及磁带等磁介质(magneticmedia)、cd-rom、dvd之类的光记录介质(opticalmedia)、软磁盘(flopticaldisk)之类的磁-光介质(magneto-opticalmedia)及rom、ram、闪存盘等专门构建的用于存储和执行程序指令的硬件装置。程序指令不仅包括通过编译器得到的机械代码，还包括能够用解释器通过计算机执行的高级语言代码。所述硬件装置可构成为作为用于执行实施例的工作的一个以上的软件模块工作，反之同理。虽然通过限定的附图对实施例进行了说明，但本
技术领域：
的一般技术人员可在所述记载的基础上进行多种修正及变形。例如，说明的技术可按照不同于说明的方法的顺序执行，及/或说明的系统、结构、装置、电路等的构成要素可以按照不同于说明的方法的其他形态结合或组合，即使被其他构成要素或等同物替代或置换也能够达到适当的结果。因此，其他构成方式、其他实施例及与专利请求范围等同的均属于专利请求范围。当前第1页12