建立针对IoT设备的注册权限机制
在构建合适的IoT设备的过程中,我们首先要认识到设备的认证和授权方并不相同。终端用户是IoT设备实际上被认证的对象,而管理平台则管理着IoT设备的授权。前者决定了设备到底要如何作为认证对象去服务,而后者则控制着IoT设备是否有权可以与这些用户进行交互。
同时,我们也不得不认识到设备本身也存在两种类别,一种位于green field,仍然在开发并生产中的设备,以及已经在使用并被部署的设备。同时,辅助层及其对应的规则引擎,组配置以及设备分类等也需要在构建机制的过程中详细考虑。
-
预嵌入信任根证书
该证书在设备制造的时刻,就已经被嵌入到设备之中,其可以是一个key,一串独特序列码,一种证书 EAP-TLS ,甚至是出生证书,基于TPM或者PUF的安全硬件单元一般被当作主要的存储工具。 -
设备白名单
用户主动联系终端,发送一些列标识符用于认证设备,比如MAC地址,并借此创建RA中认可的白名单,同时在创建之后,RA会创建一次预查。当然,随着时代的发展,单纯使用MAC进行认证是一种不太安全也不太稳定的方式,部分设备的操作系统钟的MAC是随每次网络连接而动态生成的。 -
挑战激应
RA也能主动发送一个挑战给物联网设备,同时该设备可以使用一个公钥,如果公钥位于预先提供的白名单那制上,那么RA就可以挑战设备来证明对所要获取的私钥的所有权。一个成功的check将会让设备被认可并被给与证书。 -
行为信号
对于没有预先嵌入ROT的IoT设备,相对不那么安全的认证方式一般被采用,比如说使用设备的行为特征来决定是否该设备或者这一类的设备都应该被录用。有一种方法就是抓取系统文件中的hash序列并且进行对比,以获得一系列设备指纹。 -
环境检查
而环境特征也可以被设备使用来完成相关联的部署,举例而言,可以混合IP地址和时间窗口来定位一个发向RA的请求地理源,并以此判断这是一个预编程的计划,虽然不够完全安全,但是已经是一个不错的方案。 -
一次信任事件
这种认证方式是一次性的,既受限于事件也受限于空间,可以使用一个初始的设备认证符,也可以使用一个ROT,这一认证过程越早完成,设备本身认证的过程越早结束。
目前暂时整理了这几种认证方式,可能还有更多。
在作者的眼中,虽然这些方法多样,但是实际上只有两种
一种是基于外部证明的,ip,credibility, token, PKI等: external proof-based identity model。
另外一种则是内部激应的:internal excitation-based identity model。
这两种具体的身份模型笔者将会在下一篇文章中详细介绍。
Tips:
- 坚持自我,把握当下。