通信端的安全方案设计

1各业务流程设计

1.1密钥更新业务流程

KDC的主要功能就是对密钥进行管理，该加密系统采用三层密钥体系进行加密，一层密钥用于更新二层密钥的时候对其加解密，二层密钥用于对三层密钥进行加解密。为了信息安全，一层密钥和二层密钥的下发采用加密卡和KDC直接连接，通过KDC里面的写卡程序直接把密钥写入加密卡。用户可以通过终端主动触发2层密钥更新请求，包括短彩信密钥（smkey）、点呼密钥（KEK）和组呼密钥，每次只能更新其中一种。KDC收到密钥更新请求后，产生2层密钥，使用一层密钥加密发给终端，终端更新之后返回密钥更新确认。KDC维护的2层密钥生命周期到之后，也可以主动发起密钥更新流程，流程和终端主动发起一样。

1.2CM（加密卡）与KDC认证流程

加密卡只有在开卡的KDC下才能发起点呼、组呼等后续的流程，所以在终端开机的时候，加密卡和KDC需要双向认证。终端开机后，触发CM产生终端开机认证请求，经过AFEE发给KDC，KDC验证终端合法之后，把2层密钥加密过后发终端，终端把收到的密钥分发消息给CM进行验证，验证通过之后，发送认证正确消息给KDC，完成双向认证。同时终端获取除组呼之外的2层密钥。认证失败返回认证失败消息。

1.3、加密点呼业务流程

加密系统支持UE之间加密点呼，支持一话一密。、支持业务发起前的明/密文通信选择，不支持业务中间变更。不支持UE和调度员或网关用户等在线用户之间的加密点呼。终端选择以密文方式发起点呼，消息中携带CM产生的密钥请求通知CNS。CNS收到加密点呼请求后转成SIP命令发给MDC。MDC收到消息后，检查是否是调度员或者网关用户发起，如果是就直接拒绝，如果不是则像AFEE申请点呼会话密钥申请请求。AFEE收到消息后向KDC申请点呼密钥，KDC收到请求后把主叫密钥和被叫密钥通过2层密钥加密过后同时下发给AFEE，AFEE再下发给调度机。调度机把密钥下发给CNS，CNS拿到密钥过后建立好主被叫的专用承载并且把密钥下发给UE，主被叫分别用自己的2层密钥解密这次点呼回话的密钥，开始点呼通话。

1.4加密组呼业务流程

加密系统支持UE之间加密组呼，支持一话一密，迟后进入。支持业务发起前的明/密文通信选择，不支持业务中间变更。凡是包括调度员的密文群组呼叫，调度机无法监听。终端选择以密文方式发起群组业务，消息中携带CM产生的密钥请求通知CNS。CNS收到加密组呼请求后转成SIP命令发给MDC。MDC收到消息后向AFEE申请加密组呼会话密钥申请请求。AFEE收到消息后向KDC申请组呼密钥，KDC收到请求后把群组密钥通过2层密钥加密过后同时下发给AFEE，AFEE再下发给调度机。调度机把密钥下发给CNS，CNS拿到密钥过后建立好专用承载并且把密钥下发给群组内的加密UE，群组内的加密终端用2层密钥获得本次组呼密钥过后，就可以发起加密上行数据。

1.5加密短彩信业务流程

短彩信发送者向KDC申请短彩信加密密钥，KDC返回发送方smkey加密的密钥A和接受方的smkey加密的密钥B。发送方使用A加密短/彩信之后，把密钥B一同发给接受方，接受方使用密钥B解开短彩信，恢复成明文。

2总结

通过对移动通信端到端加密的研究，给出了整个系统框架和各业务流程，该方案实现了点呼加密，组呼加密，短彩信加密等功能。

作者：陈勇 林涛 沈仁波 单位：成都理工大学信息科学与技术学院