杭州市居所出入智能门禁服务管理平台接入规范v105.docx
《杭州市居所出入智能门禁服务管理平台接入规范v105.docx》由会员分享，可在线阅读，更多相关《杭州市居所出入智能门禁服务管理平台接入规范v105.docx（115页珍藏版）》请在冰点文库上搜索。
杭州市居所出入智能门禁服务管理平台接入规范v105
杭州市居所出入（智能门禁）服务管理平台接入规范
（V1.0.5）
2015年10月
1背景目标
1.1项目背景
我市流动人口的涌入，不仅为杭州城市建设、经济发展提供了充足的人力资源，做出积极的贡献，但与此同时，流动人口的大量聚集以及流动性和不确定性，给城市带来了社会治安、文化教育、计划生育等一系列管理难题。
依据《涉密略》（浙委办〔2014〕5号）、《涉密略》（杭委办〔2014〕75号）、《杭州市流动人口服务管理条例》、《杭州市人民政府办公厅关于组织申报杭州市2014年政府系统政府投资信息化建设项目的通知》、《关于印发“智慧杭州”建设总体规划（2012-2015）的通知》等条例和文件要求，提出流动人口动态信息（居所出入智能门禁）管控平台建设需求。
1.2项目目标
以动态信息中的“住”信息采集为目标，采用物联网技术，通过居所智能门禁前端对流动人口相关信息的实时和动态采集，建立流动人口“住”信息数据库，通过对本项目平台的建设及应用，提高流动人口居所的安全性，规范流动人口信息采集的流程，促进流动人口居住信息登记质量，提升政府相关部门服务管理水平。
1.3适用范围
本《规范》是杭州市居所出入（智能门禁）服务管理平台（以下简称“市平台”）的接入规范指导，是杭州市范围内各类智能门禁系统的数据、设备接入市平台基本依据。
本《规范》适用于杭州市范围内所有已建智能门禁项目改造和新建智能门禁项目。
本《规范》适用于杭州市范围内具有智能门禁管理要求的住宅小区、出租屋、企业以及其他形式的社区和场所，包含老旧居所改造、新建居所等场景。
2规范性引用文件和术语定义
2.1规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。
本规范引用的文件均不注日期，其最新版本适用于本标准。
DB3301/T0007流动人口信息居所出入服务管理系统建设规范
GB/T2260中华人民共和国行政区划代码
GB/T2261.1人的性别代码
GB/T3304中国各民族名称的罗马字母拼写法和代码
GB/T4766婚姻状况代码
GB/T10114县级以下行政区划代码编制规则
GB/T14916识别卡物理特性
GB/T16260软件工程产品质量
GB/T22239信息安全技术信息系统安全等级保护基本要求
GB/T23705数字城市地址信息公共平台地名/地址编码规则
GB/Z28828信息安全技术公共及商用服务信息系统个人信息保护指南
GB50348安全防范工程技术规范
GB50396出入口控制系统工程设计规范
GA56.2暂住人口基本信息管理标准
GA374电子防盗锁国家标准
2.2术语定义
下列术语和定义适用于本规范。
1、流动人口
指在本市区居住的非本市区户籍的人员，以及其他县（市）居住的非本县（市）户籍的人员，不包括境外人员。
2、流动人口居所出入信息
主要包括流动人口姓名、性别、民族、出生日期、公民身份号码、户籍地址、现居住地址、历史居住记录、实时开门记录等信息。
3、流动人口综合信息平台
在专网或VPN上运行，汇集、整合城乡建设、公安、民政、人力社保、教育、计生等部门采集的流动人口信息，并实现共享的信息系统。
4、流动人口居所出入服务管理系统
流动人口居所出入服务管理系统由居所出入平台、传输网络、前端设备、出入卡、密钥管理系统等部分组成，以下简称“居所出入系统”。
5、居所出入平台
在专网或VPN上运行的信息系统，具有流动人口居所出入信息采集、管理、应用和居所出入卡管理、用户权限分类设定和管理、报警管理等功能。
6、前端设备
指特定用于流动人口居所出入信息采集，由识读设备、管理控制设备、执行设备和传输设备等组成的安装在门端的设备集合。
7、居所出入卡
指应用于居所出入系统，具有个人信息存储、门禁认证及附加应用功能的非接触集成电路卡，以下简称“出入卡”（包含集成居所出入功能的“市民卡”等）。
3第三方接入规范
3.1接入原则
1、已建设项目
杭州市范围内需要接入市平台的所有已建设完成的智能门禁项目，使用现有平台接入市平台，依据规范上传数据至市平台。
2、建设中项目
杭州市范围内需要接入市平台的所有建设中的智能门禁项目，根据项目建设情况，酌情选择使用平台接入或者设备直接接入市平台，依据规范上传数据至市平台。
3、待建设项目
杭州市范围内需要接入市平台的所有待建设的智能门禁项目，使用门禁设备或平台直接接入市平台，依据规范上传数据至市平台，同时使用市平台实现逐级管理相关门禁设备。
3.2接入流程
3.2.1接入流程图
3.2.2设备接入流程
3.2.2.1接入申请提交、审核
1、申请资料提交
杭州市范围内需要使用门禁设备直接接入市平台的智能门禁项目，项目业主或者承建单位需要书面提交接入申请和相关资料，资料包括但不限于：
接入申请书、项目概况、项目周期、承建单位概况、接入技术实现方案、接入规模、联系人、联系方式等。
2、市平台承建单位验证测试
市平台承建单位根据接入申请资料中技术方案对接入方案进行验证测试，出具验证测试报告提供市流口办参考。
3、市流口办审核
市流口办依据相关规范流程、接入申请资料和验证测试报告对接入方进行审核。
4、发布审核结论
市流口办对接入方审核完成后，通过规定的途径发布审核结论，对于审核通过的接入方，分配接入所需的市平台账号密码、厂商代码等资料，对于审核未通过的接入方，反馈相关问题给接入方，督促尽快完善相关资料。
3.2.2.2接入调试、评估
1、接入方产品开发
接入方依据市平台接入规范相关要求开发待接入市平台的产品。
2、技术联调
接入方产品开发完成后，依据市平台接入规范相关要求与市平台承建单位进行技术联调，确认产品各项参数是否符合要求，是否能够正常的接入市平台。
3、接入产品完善
若接入方产品经过联调，发现相关问题影响产品接入市平台，需对产品进行完善。
4、接入试运行
接入方认为产品完全满足市平台接入规范相关要求，同时确认产品可正常稳定的接入市平台后，接入方选取一定数量的产品接入至市平台试运行一段时间（具体试运行数量和时间由市流口办确定）。
5、市平台承建单位验证测试
市平台承建单位从技术角度、上传数据角度等对接入方进行验证测试，并出具验证测试报告供市流口办参考。
6、市流口办评估并发布结果
市流口办依据相关规范流程、验证测试报告等对接入方进行评估，并通过规定的途径发布评估结果，对于评估通过的接入方，流口办书面下发准入证明，准予正式接入市平台，对于评估未通过的接入方，反馈相关问题给接入方，督促尽快完成技术整改。
3.2.2.3正式接入、定期评估
1、正式接入
接入方依据市平台接入规范相关要求，提供接入产品的详细信息，包括但不限于：
出品商、生产日期、产品序列号、产品MAC地址等，接入方接入相关产品时，市流口办或者市平台承建单位依据相关信息，验证每一个接入市平台产品的合法性。
2、流口办定期发起评估要求
在市平台正常运行期间，流口办可定期发起接入产品评估要求，抽查若干产品进行评估，确保所有接入产品符合市平台接入规范。
3、市平台承建单位验证测试
市平台承建单位从技术角度、上传数据角度等对抽查产品进行验证测试，并出具验证测试报告供市流口办参考。
4、市流口办评估并发布结果
市流口办依据相关规范流程、验证测试报告等对抽查产品进行评估，并通过规定的途径发布评估结果，对于通过评估的产品接入方，流口办书面下发验收通过报告，对于未通过评估的产品接入方，暂停其接入资格，反馈相关问题给接入方，督促尽快完成技术整改。
3.2.3平台接入流程
3.2.3.1接入申请提交、审核
1、申请资料提交
杭州市范围内需要使用现有平台接入市平台的智能门禁项目，项目业主或者承建单位需要书面提交接入申请和相关资料，资料包括但不限于：
接入申请书、项目概况、项目周期、承建单位概况、接入技术实现方案、接入规模、联系人、联系方式等。
2、市平台承建单位验证测试
市平台承建单位根据接入申请资料中技术方案对接入方案进行验证测试，出具验证测试报告提供市流口办参考。
3、市流口办审核
市流口办依据相关规范流程、接入申请资料和验证测试报告对接入方进行审核。
4、发布审核结论
市流口办对接入方审核完成后，通过规定的途径发布审核结论，对于审核通过的接入方，分配接入所需的接口地址、接口账号密码、厂商代码等资料，对于审核未通过的接入方，反馈相关问题给接入方，督促尽快完善相关资料。
3.2.3.2接入调试、评估
1、接入方平台改造
接入方依据市平台接入规范相关要求对待接入市平台的平台进行改造，新增市平台接入相关功能。
2、技术联调
接入方平台改造完成后，依据市平台接入规范相关要求与市平台承建单位进行技术联调，确认平台各项功能是否符合要求，是否能够正常的接入市平台。
3、接入产品完善
若接入方平台经过联调，发现相关问题影响平台接入市平台，需对平台进行完善。
4、接入试运行
接入方认为平台完全满足市平台接入规范相关要求，同时确认平台可正常稳定的接入市平台后，接入方将平台接入至市平台试运行一段时间（具体试运行时间由市流口办确定）。
5、市平台承建单位验证测试
市平台承建单位从技术角度、上传数据角度等对接入方进行验证测试，并出具验证测试报告供市流口办参考。
6、市流口办评估并发布结果
市流口办依据相关规范流程、验证测试报告等对接入方进行评估，并通过规定的途径发布评估结果，对于评估通过的接入方，流口办书面下发准入证明，准予正式接入市平台，对于评估未通过的接入方，反馈相关问题给接入方，督促尽快完成技术整改。
3.2.3.3正式接入、定期评估
1、正式接入
接入方依据市平台接入规范相关要求，提供接入平台的详细信息，包括但不限于：
出品商、公网IP、服务器网络MAC地址等，接入方接入相关平台时，市流口办或者市平台承建单位依据相关信息，验证每一个接入市平台的平台合法性。
2、流口办定期发起评估要求
在市平台正常运行期间，流口办可定期发起接入平台评估要求，抽查若干平台进行评估，确保所有接入平台符合市平台接入规范。
3、市平台承建单位验证测试
市平台承建单位从技术角度、上传数据角度等对抽查平台进行验证测试，并出具验证测试报告供市流口办参考。
4、市流口办评估并发布结果
市流口办依据相关规范流程、验证测试报告等对抽查平台进行评估，并通过规定的途径发布评估结果，对于通过评估的平台接入方，流口办书面下发验收通过报告，对于未通过评估的平台接入方，暂停其接入资格，反馈相关问题给接入方，督促尽快完成技术整改。
4第三方接入接口协议
4.1设备接入接口协议
4.1.1设备接入要求
4.1.1.1设计原则与目标
简化通信协议形式（减少冗余）
节约GPRS流量
数据安全
可扩展性
兼容Internet/GPRS方案
4.1.1.2物理连接
GPRS/3G网接入
宽带接入
4.1.1.3通信方式
TCP短连接，承载业务命令
UDP长连接，实现唤醒通知机制（可选）
SMS短信通道，实现唤醒通知机制（可选）
UDP高速数据通道
4.1.2设备管理机制
4.1.2.1设备状态管理
4.1.2.1.1主控器状态
主控器的工作状态可以从uploadStatus或者queryStatus等指令中获得，工作状态是一个字节，0代表主控器正常工作，其他数字代表异常状态码
主控器的联机状态，主要由唤醒通道的可用性和TCP安全信道的可用性两者组成。
假设用1个字节来表达联机状态。
Bit0-bit3：
低半字节代表主控器唤醒通道（UDP/短信）的可用性
0000代表不可用
0001代表短信通道可用
0010代表UDP通道可用
Bit4：
是否建立了TCP安全信道连接
0代表NOTCONNECTED
1代表CONNECTED
如果主控器异常无法连接中心服务器（比如主控器断电、无法上网等），服务器是没有办法主动得知这种状态的。
所以只能设定主控器定期上传一个“活跃”事件，当服务器超出一定时间后没有获得“活跃”事件，就可以标记这一主控器处于异常状态，以便发出告警，让管理人员人工干预（比如现场检查）。
4.1.2.1.2门锁状态
门锁的状态，包括门锁的联机状态（是否与主控器正常的建立了连接），门锁自身的工作状态、门锁电池电量、温度等参数组成。
门锁没有TCP连接状态，但是和主控器一样，也要根据最后一次状态更新的时间戳，如果长时间没有更新状态，则可以判定门锁异常。
4.1.2.2设备密钥管理
4.1.2.2.1主控器密钥
在主控器上保存了多组密钥，每组密钥做不同的用途。
密钥编号
算法类型
长度
密钥用途
使用频率
（无）
DES/3DES
16
临时会话密钥，在建立TCP安全信道的时候协商产生，不允许通过SetupKey指令修改
频繁
0x01
DES/3DES
16
认证密钥，在建立安全通道的时候使用，用于客户端和服务端相互认证身份。
允许通过SetupKey指令修改。
中
0x02
DES/3DES
16
DEK密钥，加密敏感数据，在SetupKey指令中，用于加密新密钥。
允许通过SetupKey指令修改。
低
0x03
DES/3DES
16
短信通知密钥，只能用于加密唤醒通知短信
中
16字节的密钥，在DES运算中，只取用前8字节。
4.1.2.2.2PSAM卡密钥
PSAM卡上保存了SM1加解密用的SM1密钥，具体细节参考PSAM卡规范。
4.1.2.2.3临时会话密钥
临时会话密钥在TCP安全信道建立的时候协商而来，只有在session生命周期内有效。
4.1.2.3时间同步机制
主控器与门锁等设备有时需要相对精确的时间，为了获得标准时间，本协议提供两种时间同步机制。
1、通过在主控器上配置公共NTP/SNTP服务器地址，从INTERNET上获得标准时间。
2、提供一种简单的内部校时机制，从协议服务器上获得时间。
如果允许的话，建议使用公共NTP/SNTP服务器做时间同步。
第二种内部较时方案只是作为备选。
内部较时的原理如下：
服务器提供一条获取时间的指令。
假设客户端，在本地时间a这个时间点上，发出读时间指令，在本地时间点b获得了指令放回，返回值是服务器时间值x；假设客户端与标准时间（即服务器时间）相差Δt（即标准时间=客户端时间+Δt）。
那么：
指令上行延迟Δup=x-（a+Δt）
指令下行延迟Δdown=（b+Δt）-x
指令总共消耗的时间是Δtotal=Δup+Δdown=b-a
上下行延迟主要决定于网络延迟，上下行延迟的比例主要决定于网络延迟网络上下行速率比例，这一参数和具体的网络状况有关，比如GPRS一般下行速率比上行速率大。
假设比例参数k=Δdown/Δtotal，在同一时段、同一网络环境下是一个相对稳定的数字。
k=Δdown/Δtotal=（（b+Δt）-x）/（b-a）
Δt=x-b+k*（b-a）
k的取值范围在（0,1）区间内，考虑极限值：
k=0的情况下：
Δt_min=x-b
k=1的情况下：
Δt_max=x-b+（b-a）=x-a
在延迟很小的情况下（例如b-a<=2秒），如果时钟精度允许，可以取常量k=0.5，则：
Δt≈x-（b+a）/2
上下误差不超过（b-a）/2。
如果延迟大，时钟精度要求更高，还可以连续多次采样，根据短时间内比例参数相对稳定的原理设计算法，使得Δt的误差更小，具体流程算法不在本协议约束范围之内。
为了减少误差，读时间指令的请求和回复，应该以明文方式传输，不加密，协议服务器在这条指令的处理上应该提高处理优先级。
4.1.2.4拍照器管理机制
拍照器根据来源于门锁（门锁联动）、红外感应、或者用户手动拍照命令等事件，触发一次连续的拍照动作，产生一组照片文件的过程，称为一次拍照事件。
照片文件存储在拍照器的存储空间（如SD卡）内，照片文件的文件名遵从以下规则：
文件名：
T-yyyyMMdd-hhmmss-NN.jpg
T为拍照事件类型（1个字符），目前的定义：
A正常场景拍照（比如刷卡开门）
U用户（从管理平台发起）手动拍照
W强行闯入拍照
yyyyMMdd-hhmmss是拍照事件发起的时间戳，单位精度到秒。
NN为照片序号（十进制数字），同一组照片中的第一张照片序号为01，第二张序号为02，以此类推。
特殊序号00代表这组照片的缩略图。
当存储空间内剩余空间不足时，优先自动删除7天以前最老的正常场景照片，如果还不足，再删除7天以前最老的手动拍照照片，如果空间还是不足，分两种状况：
第一种，如果即将拍摄的强行闯入类的照片，则可以删除最老的强行闯入照片，以重用存储空间；如果不是强行闯入类的照片，则提示拍照失败（通过返回告警等方式，如果是用户平台手动拍照，可以返回错误码）。
每张照片上都应该有时间戳水印（实际拍照时间，而不是策略发生时间），如果可以的话，最好还要打上地址水印，如“XXX小区5单元楼道”，此地址信息通过SetupParameter配置到终端上。
4.1.3设备通信机制
4.1.3.1短链接链路超时与持续机制
TCP安全信道上，如果在N分钟内没有数据，则认为链路超时，服务器或者客户端应该自动断开此连接。
一般约定超时时间N=3分钟，但是不做强制要求。
为了延长链路持续时间（比如某条指令请求需要花费比较长的时间去执行），客户端可以发送特殊报文0x0002，以避免超时，服务端收到这个特殊报文后，除了标记时间戳，延长等待时间外，不做任何回复。
4.1.3.2数据报文中转机制
如果超过2方的节点之间需要进行中转
4.1.3.3避免GPRS拥堵机制
在繁忙时段，主控器可以通过hash分时机制，减少GPRS拥堵的几率。
繁忙时段的判定有两种，一种是通过SetupParameter，在主控器上设定已知的繁忙时段，另一种是主控器尝试建立GPRS（TCP/UDP）连接超过2次出错，则自动当作繁忙时段。
类似于“强行闯入告警”之类优先级比较高的控制命令，不强制要求按照分时算法的限制。
Hash分时机制，是对主控器地址计算hash值，以此为依据，设计分时算法。
TODO：
分时原理
4.1.3.4通用命令应答机制
一般的业务指令都是由请求/回复构成。
请求和回复通过4字节的指令流水号配对。
请求发起方生成新的指令流水号。
响应方使用这个流水号产生回复报文。
回复报文中的指令码为原请求报文指令码的最高bit置1，如请求指令0x01的回复报文中指令码为0x81。
回复报文中除了流水号外，还有错误状态编码。
在本规范中，除了状态码0代表成功外，其他数值都是错误编码。
4.1.3.5TCP安全通信机制
通信节点之间，通过TCP安全信道，来保证报文传输的安全性。
一次安全信道的会话（session），有以下几个属性：
1、会话ID（sessionId）由服务器生成的8个字节的数组，用来唯一标识某个安全信道会话。
此数据属于公开数据，允许在网络上以明文方式传输。
2、会话数据加密算法时所使用的对称算法类型，如DES/3DES等，由通信双方约定。
3、会话密钥（sessionKey）。
由通信双方在初始化（建立安全信道）的流程中协商得到。
这个数据是属于隐私数据，由通信双方各自保存，不会在网络上以明文的方式传递。
会话密钥的长度是16个字节，如果加密算法是DES，则实际使用中，只采用前8字节。
4、对于短连接，会话持续及超时时间，一个安全信道会话建立后，空闲等待30分钟后超时失效。
4.1.3.6建立安全信道会话
Step1.建立TCP连接后，服务器告知客户端，自己支持的最高协议版本号，并生成通信随机数
（S-->C）WELCOME:
version服务器支持的最高协议版本号
random1服务端随机数8bytes
Step2.客户端选定协议版本号，生成随机数，发送INIT命令给服务器
（C-->S）INIT_REQ:
DUID,客户端设备唯一识别码
random2,客户端生成的随机数8bytes
version协议版本号
authenticateData客户端认证数据（根据random1计算）
（S-->C）INIT_RESP:
status错误码（0代表成功）
authenticateData服务端认证数据（根据random2计算）
sessionId会话Id，8字节
*约定临时会话密钥sessionKey的生成算法：
使用认证密钥（主控器上存储的密钥编号为0x01）对明文数据（（random1xorrandom2）+（byte）0x12+（byte）0x28+6个（byte）0x00）进行3DES_CBC加密，生成16字节结果，作为临时会话密钥。
*客户端认证数据的生成算法：
第一步，使用会话密钥对明文数据（random1+（byte）0x13+（byte）0x29+6个（byte）0x00+8字节的设备唯一识别码）进行进行3DES_CBC加密（如果输入数据长度不足8个字节的整数倍，则填充0x00）
第二步，将第一步的输出结果，做MD5哈希计算，输出的16个字节作为客户端认证数据数据。
*服务端认证数据的生成算法：
第一步，使用会话密钥对明文数据（random2+（byte）0x14+（byte）0x30+6个（byte）0x00+8字节的设备唯一识别码）进行进行3DES_CBC加密（如果输入数据长度不足8个字节的整数倍，则填充0x00）
第二步，将第一步的输出结果，做MD5哈希计算，输出的16个字节作为客户端认证数据数据。
客户端和服务器端双方相互认证合法性后，session正式建立。
4.1.3.7重用安全信道会话
在会话有效期内，会话可以重用。
Step1.建立TCP连接后，服务器告知客户端，自己支持的最高协议版本号，并生成通信随机数
（S-->C）WELCOME:
protocolVersion服务器支持的最高协议版本号
random1服务端随机数8bytes
Step2.客户端跳过INIT命令，直接发送控制命令，同时携带session验证数据。
（C-->S）COMMANDWITHSESSION_DATA：
sessionId会话Id，8字节
authenticateData客户端认证数据（对random1进行加密，以供服务器验证合法性）
（S-->C）COMMANDRESPONSE:
status错误码（0代表成功）
如果sessionId过期或者非法，status提示ERROR_INVALID_SESSION。
客户端应该重新走INIT流程，建立安全通道后，重发这个控制命令。
4.1.3.8SM1-LV分组机制
假设分组长度为N，加密过程是：
首先把原始数据切分成长度为（N-1）的一个个分组，在每组数据前面加上本组长度字节L，分别进行SM1_ECB运算，如果长度不足，填充800000...；再把各组加密结果拼接在一起就组成了加密输出。
解密过程则相反：
首先把密文数据切分成长度为N的一个个
升级会员 