3.1 注册中心
从预警发布整个业务流程考虑,设计入网注册技术架构,规范各类客户端的合法性接入。注册中心是紧急地震信息发布系统中的管理和控制单元。注册中心维护信息服务过程中对象及信息流的定义,使整个流程中的参与对象及相互服务的过程受控。所有对象都需要在注册中心注册,才能参与服务过程; 所有服务需要在注册中心登记才能向其它对象开放; 只有申请授权后,才能访问其它对象。
对象按服务关系分为服务提供者、服务消费者,任意对象既可以是服务提供者又可以是服务消费者。在服务关系建立过程中,服务消费者向服务提供者发起连接请求时,服务提供者向注册中心验证授权。
紧急地震信息发布系统是整个预警工程的中间层,从业务架构上看,数据接入层处理源数据接入,业务应用层处理客户端接入。注册中心要实现客户端和服务端进行合法性认证,对相关服务进行授权管理。用户对象注册授权流程如图3所示。
图3 用户对象注册授权流程图
Fig.3 Authorization process of the user object registration
注册中心对象包括预警终端、预警发布端和MQTT Broker。根据服务对象的类型,采用不同的认证方式:
(1)物联网终端设备,通过授权码(CDkey)认证,对客户端授权用户名、密码和ClientID。
(2)客户端通过CDkey进行认证申请,注册中心对客户端授权Token,完成授权。
注册中心发布CDKey、AppKey、ClientID、username、password等信息,并对MQTT服务、授权服务等统一管理。客户端需要进行入网注册后,才能接入MQTT服务,并订阅消息主题,接收消息,注册流程如下:
(1)注册中心通过客户端的S/N(MAC)计算生成CDKey,CDKey为UUID,用于客户端注册。UUID是入网许可的唯一辨识码,长度是128 bit,由32个16进制数值组成。
(2)终端通过CDKey注册,注册申请信息包括设备类型、所属机构、经度、纬度、CDKey、S/N等。
(3)注册中心验证客户端的CDKey和S/N,验证通过后注册中心登记设备注册信息,并将注册信息返回给终端,包括:ClientID、AppKey、username、password、ServiceList。
ClientID由CDKey计算生成,是客户端与注册中心、MQTT服务信息交互的唯一身份认证。AppKey、username、password用于客户端与注册中心的授权管理相关访问。ServiceList为信息服务列表,客户端依据ServiceList向注册中心申请授权。
(4)服务端是紧急地震信息发布系统的信息源,服务端向注册中心进行服务登记,属性包括服务名称、服务接口、认证方式。
3.2 紧急地震信息发布协议
紧急地震信息发布主要是接收预警处理系统产出预警信息,并将预警信息发布到预警终端,终端接收预警信息后以声、光、电的形式作出预警响应。
预警工程的服务对象以小型智能设备或移动设备为主,系统处理资源和网络资源有限,如何及时、可靠地对大量的终端发布预警信息是整个发布流程的关键技术。MQTT作为一种低开销、低带宽占用的通讯协议适用于地震预警发布通讯要求。
基于MQTT信息服务是对预警消息主题发布、订阅的管理,包括MQTT Broker服务、授权认证服务和日志服务。服务对象包括发布客户端(发布者)和接收客户端(订阅者)。MQTT Broker是MQTT的消息代理,接收消息发布者发布的所有消息,并通过主题过滤器处理后分发给消息订阅者。主题消息包括地震预警消息、地震速报消息以及地震烈度速报消息等,MQTT服务主题就是客户端所需的服务。MQTT授权认证服务对主题发布者和主题订阅者的身份、账号进行认证,预警终端订阅MQTT主题授权管理以及发布客户端申请发布MQTT主题授权。
授权管理服务是对紧急地震信息发布的资源管理和访问控制。信息发布服务的核心是MQTT服务,信息发布的授权管理是对MQTT Broker的授权管理,客户端获取MQTT Broker的信息,从而实现消息订阅服务。紧急地震信息服务授权UML时序图如图4所示。
图4 紧急地震信息服务授权UML时序图
Fig.4 UML of authorization to emergent earthquake information service
客户端完成注册后,注册中心会返回给客户端AppKey,AppKey是授权管理API接口验证序号,用于验证授权服务API接入的合法性。
(1)授权申请。客户端向授权服务端发送ClientID、AppKey和Topciname,请求ServiceList的访问权限,服务主题的访问权限为读、写权限。客户端的访问权限为读权限,发布客户端的访问权限为写权限。
(2)授权验证。授权服务向注册中心验证客户端的身份信息(ClientID、AppKey),验证通过后,授权服务向客户端返回ServiceMessge报文,报文信息包括MQTT Broker的url、port、topic、username、password等信息,返回信息response报文包括主题的访问地址和端口号。
(3)授权完成。将更新权限访问控制表。
(4)客户端连接登录。客户端向MQTT Broker发起请求,首先授权服务验证ClientID身份和Topic权限。验证通过后,授权服务MQTT服务器申请访问资源的Token,Token是客户端本次请求的访问凭证。授权服务将返回的Token持久化到本地,对每个客户端需要的权限以及Token信息进行映射。只要客户端请求Topic资源权限没有变化,授权服务可以返回本地缓存的Token,避免重复申请。授权服务与MQTT服务器建立验证机制,如果MQTT服务端判断Token失效,则断开连接,客户端重新申请Token。
客户端从授权服务器不仅获取Token信息,还需要获取Token的失效时间,便于客户端刷新Token,确保Token的实时有效。客户端对授权服务返回的Token做本地持久化,避免每次重连都申请Token,防止大批量客户端连接阻塞授权服务器。
授权服务首先要验证客户端的身份和请求资源是否合法,避免客户端冒用身份申请Token,或者非法申请访问资源。授权服务建立Token和ClientID映射关系、Token和Toppic资源映射关系,实现Topic资源的访问控制。Token管理更新时序图如图5所示。
图5 Token管理更新时序图
Fig.5 Sequence of Token management update
(5)消息发布。MQTT Broker是预警信息发布的代理服务,报文由3部分组成,分别是固定报头、可变报头、有效载荷。固定报头主要内容是消息的类型和QoS级别等标志位,消息类型包括CONNECT(连接)、PUBLISH(发布)、SUBSCRIBE(订阅)、SUBACK(订阅确认)、UBSUNSCRIBE(取消订阅)。有效载荷是消息的主体,消息格式采用JSON格式。JSON是对消息对象的一种封装,层次结构简洁清晰,有效提升网络传输效率(蔡寅等,2019)。MQTT协议不支持文件类型的消息发布,因此定义烈度分布图等文件类消息的url,客户端可以通过url从文件服务器加载获取文件信息。
MQTT Broker通过ClientID、username、password信息实现对客户端的安全认证。为了解耦MQTT Broker的发布服务和认证服务,需要建设外部认证服务对用户名、密码、证书以及消息主题等访问授权等信息进行统一管理。一个MQTT Broker中存在多个主题,在多对多订阅/发布模式中,不同的主题有不同的授权管理。“EEW/*”为预警消息主题,要求有秒级的消息实效性,采用“最多1次”的策略; “EQR/*、EIQR/*”是地震速报和烈度速报消息主题,要求分钟级的消息实效性,采用“至少1次”的策略。
通过Keep Alive机制保持MQTT Broker与客户端的长连接。首先设置Keep Alive参数为t,在1.5 t内,如果Broker与Client之间没有任何数据包交互,那么判定为连接已经断开。这种Keep Alive机制解决了TCP连接中半打开连接的问题(half-open connection)。通过PINGREQ/PINGRESP数据包来保证MQTT服务保持长连接,当Broker和Client之间没有任何数据包传输的时候,通过PINGREQ/PINGRESP实现Keep Alive的约定和侦测连接状态。
客户端与Broker连接正常,客户端快速重启(小于1.5 t),再重新连接Broker,在未达到1.5 t这段时间内,客户端与Broker会存在2条连接,需要Client通过Take-Over报文来断开之前的连接,然后重新建立连接。
3.3 安全机制
地震预警终端为物联网设备,数据传输协议采用MQTT,对末端计算性能要求比较低。针对现有 MQTT协议缺乏有效身份认证以及数据以明文形式传输的问题(刘泽超等,2021),因此存在窃听风险、篡改风险、冒充风险,数据的安全性得不到保障(于振中等,2019)。通过对MQTT协议以及数据传输过程进行优化,提高预警信息服务的安全性。
(1)通过UUID获取用户名、密码、权限、ClientID,用户名和密码作为连接预警服务获取预警信息的身份认证,ClientID+UUID作为终端的一个共享密钥。
(2)登陆验证后,注册中心为客户端分配ClientID,ClientID由UUID生成,通过UUID进行反向校验。
(3)对密码交换、发布信息的报文进行加密,客户端与服务器在初次建立MQTT会话时进行秘钥协商,服务器通过随机数(时间戳)U(t)生成sessionKey,避免重复性攻击。客户端的秘钥使用ClientID或AppKey,ClientID和AppKey是客户端的授权服务以及身份认证的唯一凭证,为了确保ClientID和AppKey不被暴露窃取,通过秘钥算法f[(ClientID,U(t)]生成秘钥SessionKey。秘钥交换时序如图6所示。
图6 秘钥交换时序图
Fig.6 Sequence of key exchange
(4)MQTT不支持负载均衡,为防止高并发和恶意攻击,客户端访问MQTT服务的时候,授权服务对客户端的ClientID进行验证,对于非法接入的用户进行强制下线。通过心跳报文可以保持客户端与服务端长连接,但是客户端存在假死情况,即客户端虽然心跳通讯正常,但是客户端信息处理服务已经异常,导致客户端无效连接,造成资源浪费。授权服务建立Token更新机制,避免客户端长时间非法占用MQTT服务资源,另外,通过Token更新,防止Token被截取后的非法接入。
