WO2013107152A1 - Pws签名信息验证方法、装置及系统 - Google Patents

Abstract

本发明公开了一种PWS签名信息验证方法、装置及系统，该方法包括：终端侧接收由网络侧发送的告警消息，其中，告警消息携带签名信息和密钥标识；终端侧根据密钥标识在网络侧下发的密钥中查找密钥标识对应的密钥；终端侧利用查找到的密钥对签名信息进行验证。通过运用本发明，解决了相关技术中未对PWS密钥下发及验证的过程进行描述的问题，对PWS密钥下发及验证的过程进行了描述与定义，进而使PWS可以直接验证签名信息，提升了系统的性能。

Description

PWS签名信息验证方法、 装置及系统 技术领域 本发明涉及通信领域，具体而言，涉及一种公共警报系统（Public Warning System, 简称为 PWS) 签名信息验证方法、 装置及系统。 背景技术 为了使用户能及时准确地接收到关于灾难和其它紧急情况的警报、 警告和关键信 息，第三代合作伙伴计划 (3rd Generation Partnership Project, 简称为 3GPP)定义了 PWS 业务。 在遭遇地震、 海啸、 飓风和野外火灾等灾难时， 该业务可以使得公众能采取合 适的行动以保护他们自己及其家人不受重伤、 死亡或遭受重大财产损失。 3GPP 定义的不同的通信网络， 如全球移动通信系统 （Global System of Mobile communication， 简称为 GSM )、 通用移动通信系统 （ Universal Mobile Telecommunications System, 简称为 UMTS) 和长期演进 (Long Term Evolution, 简称 为 LTE)均支持 PWS业务，并规定 PWS业务采用小区广播业务（Cell Broadcast Service, 简称为 CBS) 来承载发送。 其架构如图 1所示， 各网元的功能如下说明： 小区广播实体 （Cell Broadcast Entity, 简称为 CBE): 不属于 3GPP定义的通信网 络。 CBE负责对 CBS进行格式化， 包括将 CBS消息划分到不同的页面。 小区广播中心（Cell Broadcast Center, 简称为 CBC 属于核心网络的一部分， 可 以与多个 CBE相连。 CBC负责 CBS消息的管理， 包括： 确定 CBS消息开始广播的时 间；确定 CBS消息停止广播的时间，且指示每一个基站控制器（Base Station Controller, 简称为 BSC) /无线网络控制器 （Radio Network Controller, 简称为 RNC) 停止广播 CBS消息； 确定 CBS消息被重复广播的时间间隔； 确定广播 CBS消息的小区广播信 道等。对于 GSM网络来说， CBC与位于无线接入网络的 BSC相连； 对于 UMTS系统 来说， CBC通过 Iu接口与位于无线接入网络的 RNC相连； 对于 LTE系统来说， CBC 与核心网的移动性管理实体（Mobility Management Entity, 简称为 MME)相连。 CBC 接收到 CBE发送的警报信息后， 进行配置和封装， 发送给受影响区域的 BSC (GSM 系统）、 RNC (UMTS系统）、 MME (LTE系统）， BSC/RNC/MME再将其转发给基站 (GSM系统为 BTS、 UMTS系统为 B， LTE系统为 e B) 广播给用户。 目前定义的 CBS 业务均是在广播信道上发送的。 而目前广播信道无任何安全保 护。 攻击者可以篡改警报消息， 或者接收到警报消息后， 在其它时间在同一地区或不 同地区进行重放， 从而在公众中造成不必要的恐慌和混乱。为了防止这种情况的出现， 3GPP决定对 PWS进行安全保护， 即通过使用数字签名字段和时间戳的方法， 引入签 名算法和密钥管理方案。 终端收到广播的警报消息后， 会首先对该消息进行认证， 仅 当认证成功通过， 才确信其为一个有效的警报消息。 对于任何基于签名的认证方案， 验证方都需要获得签名方的密钥及其相应的签名 算法。 通常该密钥为一公钥， 并且需要确保该密钥是有效的。 即对于 UE侧来说， 则 需要获得签名的密钥。在当前的 3GPP规范中， 对 PWS密钥下发的过程没有进行明确 描述； 签名算法的下发过程也没有定义； 更重要的是， 在网络侧给终端侧下发告警消 息时， 终端侧如何使用网络侧下发的密钥及相应的签名算法， 更没有任何的定义。 发明内容 本发明提供了一种 PWS签名信息验证方法、装置及系统， 以至少解决相关技术中 未对 PWS密钥下发及验证的过程进行描述的问题。 根据本发明的一个方面， 提供了一种 PWS签名信息验证方法， 包括： 终端侧接收 网络侧发送的告警消息， 其中， 所述告警消息携带签名信息 （signature) 和密钥标识; 所述终端侧根据所述密钥标识在所述网络侧下发的密钥中查找与所述密钥标识对应的 密钥； 所述终端侧利用查找到的密钥对签名信息进行验证。 优选地， 所述网络侧下发的密钥包括： 当前密钥 current key和当前密钥的下一密 钥 next key。 优选地， 所述终端侧利用查找到的密钥对签名信息进行验证包括： 所述终端侧使 用所述查找到的密钥验证所述签名信息； 当所述查找到的密钥验证所述签名信息不通 过时， 所述终端侧使用所述网络侧下发的另外一个密钥对所述签名信息进行验证。 优选地，所述告警消息中携带的密钥标识为空时，对所述密钥标识进行缺省处理， 即首选当前密钥标识对应的密钥验证所述签名信息。 根据本发明的另一方面，提供了一种 PWS告警消息下发方法， 网络侧生成告警消 息， 其中， 所述告警消息中携带签名信息和密钥标识； 所述网络侧向终端侧发送所述 告警消息。 根据本发明的另一方面， 提供了一种 PWS签名信息验证方法， 包括： 网络侧向终 端侧发送告警消息， 其中， 所述告警消息中携带签名信息和密钥标识； 终端侧接收所 述告警消息后， 根据所述密钥标识在所述网络侧下发的密钥中查找与所述密钥标识对 应的密钥； 所述终端侧利用查找到的密钥对签名信息进行验证。 根据本发明的另一方面， 提供了一种 PWS签名信息验证装置， 设置于终端侧， 包 括： 接收模块， 设置为接收网络侧发送的告警消息， 其中， 所述告警消息携带签名信 息和密钥标识； 查找模块， 设置为根据所述密钥标识在所述网络侧下发的密钥中查找 与所述密钥标识对应的密钥； 验证模块， 设置为利用查找到的密钥对签名信息进行验 证。 根据本发明的另一方面， 提供了一种 PWS告警消息下发装置， 设置于网络侧， 包 括： 生成模块， 设置为生成告警消息， 其中， 所述告警消息中携带签名信息和密钥标 识； 发送模块， 设置为向终端侧发送所述告警消息。 根据本发明的另一方面，提供了一种 PWS签名信息验证系统，包括网络侧和终端 侧： 所述网络侧， 设置为向所述终端侧发送告警消息， 其中， 所述告警消息中携带签 名信息和密钥标识； 所述终端侧， 设置为接收所述告警消息后， 根据所述密钥标识在 所述网络侧下发的密钥中查找与所述密钥标识对应的密钥； 利用查找到的密钥对签名 信息进行验证。 在本发明中， 采用如下方法对告警信息进行验证： 终端侧接收由网路侧发送的告 警信息， 其中， 该告警信息携带签名信息和密钥标识 （即密钥 ID)， 终端侧根据密钥 ID查找与其相对应的密钥， 并用查找到的密钥对签名信息进行验证。 在上述验证方法 中， 告警信息不仅携带了签名信息， 还携带了密钥 ID， 终端侧可以直接利用该密钥 ID 寻找与其对应的密钥， 并根据密钥对签名信息进行验证， 解决了相关技术中未对 PWS 密钥下发及验证的过程进行描述的问题，对 PWS密钥下发及验证的过程进行了描述与 定义， 进而使 PWS可以直接验证签名信息， 缩短验证时间， 提升了系统的性能以及资 源利用率。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部分， 本发 明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的不当限定。 在附图 中： 图 1是根据相关技术的通信网络架构的示意图； 图 2是根据本发明实施例的 PWS签名信息验证方法的流程图； 图 3是根据本发明实施例的 PWS告警消息下发方法的流程图； 图 4是根据本发明实施例的 PWS签名信息验证方法的流程图； 图 5是根据本发明优选实施例一的 PWS下发签名信息流程的示意图； 图 6是根据本发明优选实施例二的 PWS下发签名信息流程的示意图； 图 7是根据本发明优选实施例三的 PWS下发告警消息流程的示意图； 图 8是根据本发明优选实施例四的 PWS下发告警消息流程的示意图； 图 9是根据本发明实施例的 PWS签名信息验证装置的结构框图； 图 10是根据本发明实施例的 PWS告警消息下发装置的结构框图； 以及 图 11是根据本发明实施例的 PWS签名信息验证系统的结构框图。 具体实施方式 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是， 在不冲突的 情况下， 本申请中的实施例及实施例中的特征可以相互组合。 基于相关技术中未对 PWS密钥下发及验证的过程进行描述的问题，本发明实施例 提供了一种 PWS签名信息验证方法，其处理流程图请参见图 2，该方法包括步骤 S202 至步骤 S206。 步骤 S202， 终端侧接收由网络侧发送的告警消息， 其中， 告警消息携带签名信息 和密钥 ID。 步骤 S204,终端侧根据密钥 ID在网络侧下发的密钥中查找与密钥 ID对应的密钥。 步骤 S206, 终端侧利用查找到的密钥对签名信息进行验证。 通过本发明实施例， 采用如下方法对告警信息进行验证： 终端侧接收由网路侧发 送的告警信息， 其中， 该告警信息携带签名信息和密钥 ID， 终端侧根据密钥 ID查找 与其相对应的密钥， 并用查找到的密钥对签名信息进行验证。 在上述验证方法中， 告 警信息不仅携带了签名信息， 还携带了密钥 ID， 终端侧可以直接利用该密钥 ID寻找 与其对应的密钥，并根据密钥对签名信息进行验证，解决了相关技术中未对 PWS密钥 下发及验证的过程进行描述的问题， 对 PWS 密钥下发及验证的过程进行了描述与定 义， 进而使 PWS可以直接验证签名信息， 缩短验证时间， 提升了系统的性能以及资源 利用率。 在进行验证的过程中， 当网络侧再次下发告警消息时， 携带签名信息及密钥 ID; 相对应的，终端侧在收到上述告警消息后，根据告警消息中携带的密钥 ID查找对应密 钥， 用该密钥直接验证签名信息， 而不必挨个验证， 提高了系统的工作效率和准确性。 如图 2所示流程，步骤 S204中提及网络侧下发密钥，具体下发的数量可以为多个， 在实施过程中，优选的， 网络侧下发的密钥可以包括当前密钥和当前密钥的下一密钥， 进而在后文中可以根据密钥 ID查找对应的密钥。 在图 2所示步骤实施的过程中， 当使用密钥对签名信息进行验证时， 终端侧可以 选择使用当前密钥（current key)验证签名信息，但当当前密钥验证签名信息不通过时， 终端侧使用当前密钥的下一密钥 （next key)对签名信息进行验证。 在具体实施时， 可 以为两个密钥及其对应的 ID加上注释， 例如， 密钥为 current key时， 当前密钥对应的 密钥 ID为 current key id, 当密钥为 next key时， 当前密钥的下一密钥对应的密钥 ID 为 next key id。 如果终端侧介绍的告警消息中的密钥标识为空， 考虑对密钥标识采用缺省处理的 方法， 即首选用 current key id对应的密钥验证签名信息， 若验证不通过， 才进一步考 虑使用 next key id对应的密钥验证签名信息。 终端侧根据接收到的密钥 ID判断所收到的签名信息的类型。其判断方式可以预先 设定， 优选地， 本实施例中给出两种。 第一种： 当收到的密钥 ID为 current key id时， 则确定为 current key (即当前密钥）； 当收到的密钥 ID为 next key id时，则确定为 next key (即当前密钥的下一密钥）。 此种方式为直接根据密钥 ID确定密钥。 进一步的， 当 密钥 ID与当前密钥对应时，终端侧使用当前密钥验证签名信息； 当当前密钥验证不通 过时， 终端侧可以选择使用当前密钥的下一密钥对签名信息进行验证。 此种方式是在 终端侧无法通过当前密钥验证的情况下进行的， 当然， 也可以先使用当前密钥的下一 密钥进行验证， 当当前密钥的下一密钥不通过的情况下， 使用当前密钥验证签名信息， 即上述过程是在签名信息无法通过验证的情况下执行的， 此种验证方式体现了系统良 好的灵活性。 本发明实施例不增加新的信令流程、 也不需要单独触发信令流程， 只在现在流程 中即可实现， 只增加若干参数， 终端侧增加逻辑处理功能。 根据本发明上述实施例终端侧接收告警信息的另一方面，网络侧需下发告警信息。 因此， 本发明实施例还提供了一种 PWS告警消息下发方法， 其处理流程如图 3所示， 包括步骤 S302至步骤 S304。 步骤 S302， 网络侧生成告警消息， 其中， 告警消息中携带签名信息和密钥 ID。 步骤 S304， 网络侧向终端侧发送告警消息。 在网络侧下发密钥的过程中， 当前密钥和当前密钥的下一密钥的定义与上述 PWS 签名信息验证的过程相似， 密钥为当前密钥 current key时， 当前密钥对应的密钥 ID 为 current key id, 密钥为当前密钥的下一密钥 next key时， 当前密钥的下一密钥对应 的密钥 ID为 next key id。 如图 3所示流程， 步骤 S302中， 网络侧生成告警消息时， 其密钥 ID可能是缺省 的， 即告警消息中不包含密钥标识。 相对应的， 终端侧接收到这一类告警消息时， 会 对其进行缺省处理。 在实施过程中， 网络侧下发， 终端侧进行接收， 此过程为一个交互的过程， 根据 该交互过程，本发明实施例还提供了一种 PWS签名信息验证方法， 图 4是根据本发明 实施例的 PWS签名信息验证方法的流程图， 该流程包括步骤 S402至步骤 S408。 步骤 S402， 网络侧向终端侧发送告警消息， 其中， 告警消息中携带签名信息和密 钥标识 ID。 步骤 S404， 终端侧接收告警消息后， 根据密钥 ID在网络侧下发的密钥中查找与 密钥 ID对应的密钥。 步骤 S406, 终端侧利用查找到的密钥对签名信息进行验证。 下面结合优选实施例对上述实施例进行进一步描述。 优选实施例一 如图 5所示， 该实施例示出了 CBC/CBE向核心网节点 MME/SGSN下发 PWS签 名安全信息的过程。 本流程既包括了初始下发过程， 也包括后续的更新过程等。 不论 哪种过程，下发消息中直接下发两个 PWS密钥，一个当前的密钥 current key和对应的 key id, 一个下一次的密钥 next key和对应的 key id。步骤包括步骤 S502至步骤 S504。 步骤 S502， CBC (或者 CBE经过 CBC) 向 MME或 SGSN下发 PWS签名安全信 息， 包括两个 PWS密钥， 一个当前的密钥 current key和对应的 key id， 一个下一次的 密钥 next key和对应的 key id。 步骤 S504， MME或 SGSN收到下发的安全信息后， 保存该安全信息， 并向 CBC 发送响应消息。 优选实施例二 如图 6所示， 该实施例示出了核心网节点 MME/SGSN向终端下发 PWS签名安全 信息的过程。 本流程既包括了初始下发过程， 也包括后续的更新过程等。 不论哪种过 程， 都是在正常的附着接受、 路由区更新响应、 跟踪区更新响应等消息中直接下发两 个 PWS密钥，一个当前的密钥 current key和对应的 key id,一个下一次的密钥 next key 和对应的 key id, 步骤包括步骤 S602至步骤 S606。 步骤 S602， UE向 MME发送正常的 attach请求、 TAU请求、 RAU请求等消息。 步骤 S604， MME向 UE发送 attach accepts TAU响应、 RAU响应等对应消息， 在该消息中向 UE下发对应的安全信息。 如果 next key升级为 current key，那么该消息中携带 current key id禾 P next key、 next key id; 如果两个 key都更新了， 那么该消息中需携带两个 key及其对应的 id。 步骤 S606， UE保存收到的安全信息， 更新本地对应的两个 key信息。 优选实施例三 如图 7所示， 该实施例示出了 LTE网络向终端下发 PWS告警消息的过程。 本流 程不仅包括了网络在向 UE下发告警消息所携带的参数信息， 而且还包含了 UE收到 该告警消息后， 如何使用本地保存的安全信息和消息中携带的安全参数来验证告警消 息的数字签名信息， 步骤包括步骤 S702至步骤 S714。 步骤 S702， CBC (或者 CBE经过 CBC) 向 MME下发写替代告警请求消息 （一 种特定告警消息）， 消息中携带数字签名信息以及签名时所用密钥对应的 Kid (即上文 提及的 key id的缩写）。 步骤 S704， MME收到该请求信息后， 向 CBC/CBE发送写替代告警确认消息。 步骤 S706， MME向 eNB发送写替代告警请求消息， 其中携带签名信息和签名所 用密钥对应的标识 Kid。 步骤 S708， eNB向 UE发送广播信息消息， 在消息中携带签名信息和签名所用密 钥对应的标识 Kid。 步骤 S710， UE根据广播信息消息中携带的 Kid对应的 key验证消息中的签名信 息。 验证过程中， 如果签名信息验证不通过， 可以使用另一个密钥来进行验证。 步骤 S712， eNB向 MME发送写替代告警响应消息。 步骤 S714， UE发出告警指示。 优选实施例四 如图 8所示， 该实施例示出了 UMTS网络向终端下发 PWS告警消息的过程。 本 流程不仅包括了网络在向 UE下发告警消息所携带的参数信息， 而且还包含了 UE收 到该告警消息后， 如何使用本地保存的安全信息和消息中携带的安全参数来验证告警 消息的数字签名信息。 步骤包括步骤 S802至步骤 S812。 步骤 S802， CBC (或者 CBE经过 CBC) 向 RNC下发写替代告警请求消息， 消息 中携带数字签名信息以及签名时所用密钥对应的 Kid。 步骤 S804， RNC向 NodeB发送广播请求消息， 其中携带签名信息和签名所用密 钥对应的标识 Kid。 步骤 S806， NodeB向 UE发送广播信息消息。 步骤 S808， NodeB向 UE发送寻呼消息 步骤 S810， NodeB向 UE带安全信息的主通告消息， 在消息中携带签名信息和签 名所用密钥对用的标识 Kid。 步骤 S812， UE根据广播信息消息中携带的 Kid对应的 key验证消息中的签名信 息。 在实施过程中， 当签名信息验证不通过时， 可以试探使用另一个密钥来验证。 可 选地， 如果广播信息消息中没有携带 Kid， 那么首先 current key验证， 不通过的情况 下再使用 next key验证。 步骤 S814， UE发出告警指示。 步骤 S816， RNC向 CBC/CBE发送报告成功消息。 在实施过程中， 对于 GSM网络， 流程与上述步骤 S802至 S816基本一致的， 只 需把 RNC替换成 BSC, NodeB替换成 BTS即可。本实施例并不限于 LTE系统、 UMTS 系统和 GSM/GERAN系统的 PWS签名安全信息下发和使用方法， 可以将它的相关模 式应用于其它无线通信系统中。 根据本发明实施例的另一方面，还提供了一种 PWS签名信息验证装置，设置于终 端侧， 如图 9所示， 是根据本发明实施例的 PWS签名信息验证装置的结构框图， 该装 置包括： 接收模块 10， 设置为接收由网络侧发送的告警消息， 其中， 告警消息携带签 名信息和密钥标识 ID; 查找模块 20， 与接收模块 10耦合， 设置为根据密钥 ID在网 络侧下发的密钥中查找与密钥 ID对应的密钥； 验证模块 30， 与查找模块 20耦合， 设 置为利用查找到的密钥对签名信息进行验证。 相对于上述设置于终端侧的 PWS签名信息验证装置，本发明实施例还提供了一种 PWS告警消息下发装置， 设置于网络侧， 如图 10所示， 是根据本发明实施例的 PWS 告警消息下发装置的结构框图， 该装置包括： 生成模块 40， 设置为生成告警消息， 其 中， 告警消息中携带签名信息和密钥标识； 发送模块 50， 与生成模块 40耦合， 设置 为向终端侧发送告警消息。 基于上述装置的交互过程，本发明实施例还提供一种 PWS签名信息验证系统，如 图 11所示， 该系统包括网络侧 1和终端侧 2: 网络侧 1， 设置为向终端侧 2发送告警 消息， 其中， 告警消息中携带签名信息和密钥标识； 终端侧 2， 设置为接收告警消息 后， 根据密钥标识在网络侧 1下发的密钥中查找密钥标识对应的密钥， 其中， 网络侧 1 下发的密钥包括： 当前密钥和当前密钥的下一密钥； 利用查找到的密钥对签名信息 进行验证。 从以上的描述中， 可以看出， 本发明实现了如下技术效果： 在本发明实施例中， 采用如下方法对告警信息进行验证： 终端侧接收由网路侧发 送的告警信息， 其中， 该告警信息携带签名信息和密钥 ID， 终端侧根据密钥 ID查找 与其相对应的密钥， 并用查找到的密钥对签名信息进行验证。 在上述验证方法中， 告 警信息不仅携带了签名信息， 还携带了密钥 ID， 终端侧可以直接利用该密钥 ID寻找 与其对应的密钥，并根据密钥对签名信息进行验证，解决了相关技术中未对 PWS密钥 下发及验证的过程进行描述的问题， 对 PWS 密钥下发及验证的过程进行了描述与定 义， 进而使 PWS可以直接验证签名信息， 缩短验证时间， 提升了系统的性能以及资源 利用率。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装置所 组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现， 从而， 可以 将它们存储在存储装置中由计算装置来执行， 并且在某些情况下， 可以以不同于此处 的顺序执行所示出或描述的步骤， 或者将它们分别制作成各个集成电路模块， 或者将 它们中的多个模块或步骤制作成单个集成电路模块来实现。 这样， 本发明不限制于任 何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的技 术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所作的 任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。 工业实用性 本发明的技术方案具有工业实用性： 终端侧接收由网路侧发送的告警信息，其中， 该告警信息携带签名信息和密钥 ID， 终端侧根据密钥 ID查找与其相对应的密钥， 并 用查找到的密钥对签名信息进行验证。 在上述对告警信息进行验证的方法中， 告警信 息不仅携带了签名信息， 还携带了密钥 ID， 终端侧可以直接利用该密钥 ID寻找与其 对应的密钥，并根据密钥对签名信息进行验证，解决了相关技术中未对 PWS密钥下发 及验证的过程进行描述的问题，对 PWS密钥下发及验证的过程进行了描述与定义，进 而使 PWS可以直接验证签名信息，缩短验证时间，提升了系统的性能以及资源利用率。

Claims

权 利 要 求 书

1. 一种公共警报系统 PWS签名信息验证方法， 包括： 终端侧接收网络侧发送的告警消息， 其中， 所述告警消息携带签名信息和 密钥标识；

所述终端侧根据所述密钥标识在所述网络侧下发的密钥中查找与所述密钥 对应的密钥；

所述终端侧利用查找到的密钥对签名信息进行验证。

2. 根据权利要求 1所述的方法， 其中， 所述网络侧下发的密钥包括： 当前密钥和 当前密钥的下一密钥。

3. 根据权利要求 1所述的方法， 其中， 所述终端侧利用查找到的密钥对签名信息 进行验证包括：

所述终端侧使用所述查找到的密钥验证所述签名信息；

当所述查找到的密钥验证所述签名信息不通过时， 所述终端侧使用所述网 络侧下发的另外一个密钥对所述签名信息进行验证。

4 根据权利要求 1所述的方法， 其中， 所述告警消息中携带的密钥标识为空时， 对所述密钥标识进行缺省处理， 即首选当前密钥标识对应的密钥验证所述签名 信息。

5. 一种公共警报系统 PWS告警消息下发方法， 包括：

网络侧生成告警消息， 其中， 所述告警消息中携带签名信息和密钥标识； 所述网络侧向终端侧发送所述告警消息。

6. 一种公共警报系统 PWS签名信息验证方法， 包括：

网络侧向终端侧发送告警消息， 其中， 所述告警消息中携带签名信息和密 钥标识；

所述终端侧接收所述告警消息后， 根据所述密钥标识在所述网络侧下发的 密钥中查找与所述密钥标识对应的密钥；

所述终端侧利用查找到的密钥对签名信息进行验证。

7. 一种公共警报系统 PWS签名信息验证装置， 设置于终端侧， 包括： 接收模块， 设置为接收网络侧发送的告警消息， 其中， 所述告警消息携带 签名信息和密钥标识；

查找模块， 设置为根据所述密钥标识在所述网络侧下发的密钥中查找与所 述密钥标识对应的密钥；

验证模块， 设置为利用查找到的密钥对签名信息进行验证。

8. —种公共警报系统 PWS告警消息下发装置， 设置于网络侧， 包括：

生成模块， 设置为生成告警消息， 其中， 所述告警消息中携带签名信息和 密钥标识；

发送模块， 设置为向终端侧发送所述告警消息。

9. 一种公共警报系统 PWS签名信息验证系统， 包括网络侧和终端侧：

所述网络侧， 设置为向所述终端侧发送告警消息， 其中， 所述告警消息中 携带签名信息和密钥标识；

所述终端侧， 设置为接收所述告警消息后， 根据所述密钥标识在所述网络 侧下发的密钥中查找与所述密钥标识对应的密钥； 利用查找到的密钥对签名信 息进行验证。