具体实施方式
下面结合附图对本发明进行进一步阐述。
一、系统结构设计说明
如图1所示为按地域分层次无线信息发布搜索交流应用系统的整体结构图,由用户接入、广域网络(互联网)、服务器和数据库四个部分组成。用户接入部分包括:Wi-Fi用户机,连有Wi-Fi用户机的移动电脑,它们通过Wi-Fi AP机接入互联网;连或不连Wi-Fi用户机的PC机(手提电脑),通过有线网络(拨号,xDSL等)接入互联网;手机,通过移动通信网接入互联网。服务器包括:认证服务器,PKI应用服务器,邮件服务器,应用服务器,Web服务器,通用浏览器用户登录认证时Web服务器是认证服务器的客户,而邮件服务器、应用服务器和Web服务器需请求PKI应用服务器的服务。数据库包括:系统信息、产品信息、用户信息数据库,它们是基础,另有邮件信息、公共信息、分类信息、即时信息、留言信息、广告信息、应用信息、PKI证书、密钥备份数据库,它们与前三个数据库相关联。
二、Wi-Fi用户机硬件设计说明
2.1硬件基本结构
如图2所示,包括处理器、程序存储、数据存储、资料存储、按键、LCD控制和显示、Wi-Fi基带处理和MAC控制、无线收发、天线、USB总线接口、用户信息模块。
处理器一般选用32位嵌入式处理器,如ARM、MIPS、68000、386EX、PowerPC等系列。由于Wi-Fi通信处理是关键,故最好选用集成Wi-Fi基带处理和MAC控制甚至无线收发功能的SOC处理器芯片,有些SOC芯片还包括了USB接口。程序存储使用EPROM,或者与资料存储一样采用FLASH闪存。数据存储使用SRAM,如果处理器支持,还可使用DRAM。资料存储使用FLASH闪存。Wi-Fi通信采用支持常用标准协议的芯片(2.4GHz),如802.11b/g/n。USB接口选2.0以上。
2.2用户信息模块
有两种方案可以选择。
2.2.1使用EEPROM
只是存放产品信息,用户信息,服务商加密公钥,用户签名、加密、解密等密钥。签名、加密、解密等算法统一到Wi-Fi用户机软件当中。
2.2.2使用IC卡
除了存放产品信息,用户信息,服务商加密公钥,用户签名、加密、解密等密钥,相关签名、加密、解密等算法也包括在内。用户信息卡结构和触点功能如图3所示(参照GSM系统SIM卡定义),由CPU、程序存储器ROM、工作存储器RAM、数据存储器EEPROM和串行通信单元5个部分组成,触点Vcc为电源、RET为复位、CLK为时钟、GND为接地、Vpp为编程电压、I/O为输入/输出。
2.3 Wi-Fi用户机结构方案选择
2.3.1做成独立产品形态
包括Wi-Fi无线通信,键盘输入,LCD显示,USB接口,用户信息模块,软件有TCP/IP协议族和上层应用软件。
产品可以独立使用。也可通过USB接口与移动手提电脑相连,连上后,如果在Wi-Fi AP机通信区域,则可通过手提电脑直接操作相关应用。还可通过USB接口与PC机或者连不上Wi-Fi AP机的手提电脑相连,虽然不能进行Wi-Fi通信连接,但如果有DSL宽带或拨号线路连接互联网,也可通过Wi-Fi用户机中的用户信息模块及相关软件进行身份认证并通过Web服务器使用某些应用服务。
2.3.2与PDA产品融合
目前PDA产品功能已很强大,很多都有了Wi-Fi无线上网的功能,因此将Wi-Fi用户机功能融合进现有的PDA产品中难度不大,具备Wi-Fi无线通信功能之后,只需加上用户信息模块,另加上特有的上层应用软件即可。使用模式与独立产品相同。
2.3.3与MP3或MP4等产品融合
可能得加上Wi-Fi无线通信,键盘输入,用户信息模块,还有TCP/IP协议族和上层应用软件。使用模式与独立产品相同。
2.3.4与手机等通信产品融合
现在手机功能越来越强越来越智能化,很多都已配备了Wi-Fi无线通信和无线上网的功能。具备Wi-Fi无线通信功能之后,另加上用户信息模块和上层应用软件即可。除了与独立产品相同的使用模式,手机在高速移动过程当中,或者在没有Wi-Fi AP机覆盖的区域,还可通过移动通信网连上互联网,并借助用户信息模块及相关软件进行身份认证并通过服务器使用某些应用服务。
2.3.5用户信息模块单独做成产品
目前大部分手提电脑都配有Wi-Fi无线网卡,对于习惯出门带手提电脑的人,做一个简化的只包括用户信息模块的产品也许更方便。
产品结构如图4所示,包括处理器、程序存储、数据存储、资料存储、用户信息存储、USB总线接口、LED状态显示。程序存储用EPROM或FLASH闪存,数据存储用SRAM,资料存储用FLASH闪存,用户信息存储用EEPROM,处理器用8位MCU(最好带有USB接口并有足够的EPROM或FLASH闪存和SRAM)。
对于带有Wi-Fi无线网卡的手提电脑,通过USB接口与用户信息模块相连后,如果在Wi-Fi AP机通信区域,则可通过手提电脑直接操作相关应用。即使不在Wi-FiAP机服务区域,手提电脑或PC机如果有DSL宽带或拨号线路连接互联网,通过USB接口连上用户信息模块后,也可借助相关软件进行身份认证并通过Web服务器使用某些应用服务。
三、Wi-Fi AP机硬件设计说明
如图5所示,包括处理器、程序存储、数据存储、资料存储、LED状态显示、Wi-Fi通信模块、以太网通信模块、广域网通信模块、ADSL通信模块。
处理器一般选用32位嵌入式处理器,如ARM、MIPS、68000、386EX、PowerPC等系列。由于Wi-FiAP机是做网关/路由器使用,故最好选用功能非常强大的专门针对Wi-FiAP设计的SOC处理器芯片,不仅集成了Wi-Fi通信功能,一般也包括了以太网通信和广域网通信功能。程序存储和资料存储都选用FLASH闪存,数据存储则选用SDRAM。
现在Wi-Fi AP已有相当成熟的商品化产品,在Wi-Fi通信和以太网通信等方面已能满足本系统的要求。考虑到本系统中Wi-Fi AP机必须连接互联网,故需要包括广域网通信功能。考虑到成本因素以及互联网接入服务商的实际情况,各热点的Wi-FiAP不一定能通过光纤连接internet,而目前用得比较多的宽带接入方式则是ADSL,故把ADSL通信功能直接加到Wi-Fi AP机中。至于Wi-Fi AP机在本系统的其它一些特殊功能和应用则是通过软件来实现。
四、身份认证和访问控制设计
4.1 Wi-Fi用户证书
对每一批Wi-Fi用户机,服务商要生成单独的签名密钥对和加密密钥对,并在产品信息数据库中进行备案记录。分配好用户识别编号后,连同其它产品信息一起用该批产品的签名私钥进行签名,生成Wi-Fi用户证书并写入Wi-Fi用户机用户信息模块当中。用户证书可同时在用户信息数据库中进行备案记录。
表4.1 Wi-Fi用户证书内容
字段 |
定义 |
说明 |
MAC地址 |
Wi-Fi网络地址 |
48bit |
SSID |
作为服务商特有名称 |
连接服务商AP的基本条件 |
产品批次 |
与签名和加密密钥对相对应 |
按一定规则编号 |
生产商 |
用于产品跟踪服务 |
按一定规则编号 |
软件系统版本号 |
用于软件跟踪服务 |
|
用户识别编号UID |
Wi-Fi用户识别标志 |
|
服务商数字签名 |
用该批产品签名私钥对用户证书的数字签名 |
|
服务商加密公钥 |
该批产品的服务商加密公钥 |
|
4.1.1用户识别编号UID编码设计
用11位以上数字进行编码,如用11位数字,格式如下所示,其中服务商编号Service-Provider-Id应在全国甚至全世界范围内统一分配。
XXX(3位数字) |
XXXX XXXX(8位数字) |
Service-Provider-Id |
Order-Number |
服务商编号 |
顺序号 |
4.2基于Wi-Fi用户机和Wi-FiAP机的用户身份认证
当用户手持Wi-Fi用户机(或者携带连有Wi-Fi用户机的手提电脑),在Wi-FiAP热点通信区域内时需进行的身份认证。认证过程如图6所示。
4.2.1建立Wi-Fi网络连接
如果Wi-Fi用户机和Wi-Fi AP机具有相同的SSID,根据Wi-Fi通信协议,即可进行网络连接,并通过AP上的DHCP自动获得IP地址。此时Wi-Fi AP通信区域内的所有Wi-Fi用户机之间已具备通常意义上的网络通信能力。
4.2.2以Access-Request包的形式提交用户证书
网络连接建好之后,Wi-Fi用户机向AP发送自己的用户证书(或者AP主动读取Wi-Fi用户机的用户证书),AP将用户证书封装成Access-Request包,并提交给认证服务器,然后等待认证服务器的响应。如果一段时间后没有响应,可反复发送一定次数。
4.2.3认证服务器验证用户证书
认证服务器根据用户证书中的产品批次找出签名密钥对,对用户证书的服务商数字签名进行核对。如果不一致就向AP返回Access-Reject包。如果一致,将生成一个随机数(超过一定位数,如8位以上),并向AP返回Access-Challenge包。
4.2.4对挑战进行回应
如果AP收到Access-Challenge包,将把挑战数字发送给Wi-Fi用户机。可提示用户按挑战数字重复输入一遍,或者不要求用户再按键输入。Wi-Fi用户机然后使用用户证书中的服务商加密公钥对数字进行加密,再将加密结果传送给AP。AP收到后,将加密结果连同AP本身信息(如位置信息)封装成Access-Request包,并再一次提交给认证服务器。
4.2.5认证服务器验证挑战回应结果
认证服务器收到挑战回应后,根据产品批次找出加密密钥对,对加密结果进行解密,并与实际的挑战数字进行比较。如果不一致就向AP返回Access-Reject包。如果一致,将根据用户识别编号UID从用户信息数据库中读取该用户的各种应用访问权限,并对用户连网信息进行注册登记,然后向AP返回Access-Accept包。
4.2.6建立访问控制表并根据用户权限对应用进行配置
如果AP收到Access-Accept包,将在AP上为该用户建立应用访问控制表,并根据整数分级权限和位或权限对Wi-Fi用户机的一级应用操作图标和菜单进行配置。
4.2.7离开AP断开Wi-Fi网络连接
如果AP检测到Wi-Fi用户离开,Wi-Fi网络连接已断开,将撤消该用户的应用访问控制表,并向认证服务器发送Access-Request包,请求认证服务器对相应用户进行连网注销登记。
4.3基于Wi-Fi用户机和有线上网并带特别客户端软件的用户身份认证
如果Wi-Fi用户机通过USB接口与PC机或手提电脑相连,不在Wi-Fi AP通信区域,但PC机或手提电脑能通过DSL宽带或拨号线路连接互联网,而且PC机或手提电脑上安装有系统认证和系统应用方面的客户端软件,此时需进行的身份认证。认证过程如图7所示。
4.3.1以Access-Request包的形式向认证服务器提交用户证书
在PC机或手提电脑上启动系统应用软件时,将首先启动系统身份认证。PC机或手提电脑读取Wi-Fi用户机的用户证书,将用户证书封装成Access-Request包,并提交给认证服务器,然后等待认证服务器的响应。如果一段时间后没有响应,可反复发送一定次数。
4.3.2认证服务器验证用户证书
认证服务器根据用户证书中的产品批次找出签名密钥对,对用户证书的服务商数字签名进行核对。如果不一致就向PC机或手提电脑返回Access-Reject包。如果一致,认证服务器将生成一个随机数(超过一定位数,如8位以上),并向PC机或手提电脑返回Access-Challenge包。
4.3.3对挑战进行回应
如果PC机或手提电脑收到Access-Challenge包,可提示用户按挑战数字重复输入一遍,或者不要求用户再按键输入。PC机或手提电脑然后请求Wi-Fi用户机使用用户证书中的服务商加密公钥对数字进行加密,并将加密结果返回。PC机或手提电脑再将加密结果封装成Access-Request包并提交给认证服务器。
4.3.4认证服务器验证挑战回应结果
认证服务器收到挑战回应后,根据产品批次找出加密密钥对,对加密结果进行解密,并与实际的挑战数字进行比较。如果不一致就向PC机或手提电脑返回Access-Reject包。如果一致,将根据用户识别编号UID从用户信息数据库中读取该用户的各种应用访问权限,并对用户连网信息进行注册登记,然后向PC机或手提电脑返回Access-Accept包。
4.3.5建立访问控制表并根据用户权限对应用进行配置
如果PC机或手提电脑收到Access-Accept包,将在PC机或手提电脑上为该用户建立应用访问控制表,并根据整数分级权限和位或权限对系统一级应用软件进行相应配置,然后正式开启系统应用软件。
4.3.6关闭系统应用软件
当用户关闭系统应用软件时,将撤消该用户的应用访问控制表,并向认证服务器发送Access-Request包,请求认证服务器对相应用户进行连网注销登记。
4.4基于Wi-Fi用户机和有线上网使用浏览器软件的用户身份认证
如果Wi-Fi用户机通过USB接口与PC机或手提电脑相连,不在Wi-Fi AP通信区域,但PC机或手提电脑能通过DSL宽带或拨号线路连接互联网,而且要通过通用的浏览器和Web服务器来使用系统应用服务,此时需进行的身份认证。认证过程如图8所示。
4.4.1向Web服务器提交用户证书
当在PC机或手提电脑上打开浏览器连接系统网址时,Web服务器如果发现没有进行身份认证,将允许用户下载身份认证页面。该页面上的特定脚本程序(或applet,或ActiveX控件)可读取Wi-Fi用户机的用户证书,用户确认身份认证页面后就可将用户证书提交给Web服务器。
4.4.2以Access-Request包的形式向认证服务器提交用户证书
Web服务器将用户证书封装成Access-Request包,并提交给认证服务器,然后等待认证服务器的响应。如果一段时间后没有响应,可反复发送一定次数。
4.4.3认证服务器验证用户证书
认证服务器根据用户证书中的产品批次找出签名密钥对,对用户证书的服务商数字签名进行核对。如果不一致就向Web服务器返回Access-Reject包。如果一致,认证服务器将生成一个随机数(超过一定位数,如8位以上),并向Web服务器返回Access-Challenge包。
4.4.4对挑战进行回应
如果Web服务器收到Access-Challenge包,将向PC机或手提电脑下载挑战页面。页面上有挑战数字,可提示用户按挑战数字重复输入一遍,或者不要求用户再按键输入。该页面上的特定脚本程序(或applet,或ActiveX控件)请求Wi-Fi用户机使用用户证书中的服务商加密公钥对数字进行加密。用户确认挑战页面后就将加密结果提交给Web服务器,Web服务器再将加密结果封装成Access-Request包并提交给认证服务器。
4.4.5认证服务器验证挑战回应结果
认证服务器收到挑战回应后,根据产品批次找出加密密钥对,对加密结果进行解密,并与实际的挑战数字进行比较。如果不一致就向Web服务器返回Access-Reject包。如果一致,将根据用户识别编号UID从用户信息数据库中读取用户各种应用访问权限,并对用户连网信息进行注册登记,然后向Web服务器返回Access-Accept包。
4.4.6建立访问控制表并配置系统应用页面
如果Web服务器收到Access-Accept包,将分别在Web服务器上和PC机或手提电脑上为用户建立应用访问控制表(一般使用Cookie),并对系统一级应用页面进行配置,然后下载到PC机或手提电脑上。为了保证用户及访问权限的后续有效性,可对用户信息、环境信息、访问控制信息并连同内部密码进行MD5计算,并将计算结果也保存下来,方便以后随时验证。如可采用以下公式进行计算:MD5(用户识别编号UID+密码串一+产品批次+挑战随机数+IP地址+密码串二+访问控制表)。
4.4.7用户会话结束
当Web服务器发现用户会话结束时,将向认证服务器发送Access-Request包,请求认证服务器对相应用户进行连网注销登记。
4.5基于用户口令和有线上网并带特别客户端软件的用户身份认证
如果没有Wi-Fi用户机,但有通过DSL宽带或拨号线路连接互联网的PC机或手提电脑,而且PC机或手提电脑上安装有系统认证和系统应用方面的客户端软件,此时需进行的身份认证。认证过程如图9所示。
每个用户识别编号对应一个用户密码,用户密码由用户自己设置,也允许用户修改。用户密码以单向加密的形式存放在用户信息数据库中,如采用计算公式MD5(用户识别编号UID+密码串一+用户密码+密码串二)进行单向加密。
针对这种认证方式,服务商要生成一对签名密钥和一对加密密钥。加密公钥以统一的标准的公钥证书形式对外发布,该证书使用服务商私钥进行签名。服务商加密公钥证书包含在系统认证和系统应用客户端软件当中。
4.5.1以Access-Request包的形式向认证服务器提交UID和用户密码
在PC机或手提电脑上启动系统应用软件时,将首先启动系统身份认证。封装Access-Request包时,用户密码可采用RADIUS协议建议的加密方式,或者使用服务商加密公钥直接加密。向认证服务器提交Access-Request包,然后等待认证服务器的响应。如果一段时间后没有响应,可反复发送一定次数。
4.5.2认证服务器验证UID和用户密码
认证服务器首先解出用户密码,再利用单向加密公式计算后与用户信息数据库中的密码进行比对。如果不一致就向PC机或手提电脑返回Access-Reject包。如果一致,认证服务器将生成一个随机数(超过一定位数,如8位以上),并向PC机或手提电脑返回Access-Challenge包。
4.5.3对挑战进行回应
如果PC机或手提电脑收到Access-Challenge包,可提示用户按挑战数字重复输入一遍,或者不要求用户再按键输入。PC机或手提电脑然后使用服务商加密公钥对数字进行加密,再将加密结果封装成Access-Request包并提交给认证服务器。
4.5.4认证服务器验证挑战回应结果
认证服务器收到挑战回应后,找出私钥,对加密结果进行解密,并与实际的挑战数字进行比较。如果不一致就向PC机或手提电脑返回Access-Reject包。如果一致,将根据用户识别编号UID从用户信息数据库中读取该用户的各种应用访问权限,并对用户连网信息进行注册登记,然后向PC机或手提电脑返回Access-Accept包。
4.5.5建立访问控制表并根据用户权限对应用进行配置
如果PC机或手提电脑收到Access-Accept包,将在PC机或手提电脑上为该用户建立应用访问控制表,并根据整数分级权限和位或权限对系统一级应用软件进行相应配置,然后正式开启系统应用软件。
4.5.6关闭系统应用软件
当用户关闭系统应用软件时,将撤消该用户的应用访问控制表,并向认证服务器发送Access-Request包,请求认证服务器对相应用户进行连网注销登记。
4.6基于用户口令和有线上网使用浏览器软件的用户身份认证
如果没有Wi-Fi用户机,但有通过DSL宽带或拨号线路连接互联网的PC机或手提电脑,而且要通过通用的浏览器和Web服务器来使用系统应用服务,此时需进行的身份认证。手机通过移动通信网连接互联网,并希望通过浏览器使用系统服务时,也采用这种认证方式。认证过程如图10所示。
每个用户识别编号对应一个用户密码,用户密码由用户自己设置,也允许用户修改。用户密码以单向加密的形式存放在用户信息数据库中,如采用计算公式MD5(用户识别编号UID+密码串一+用户密码+密码串二)进行单向加密。
针对这种认证方式,服务商要生成一对签名密钥和一对加密密钥。加密公钥以统一的标准的公钥证书形式对外发布,该证书使用服务商私钥进行签名。
4.6.1向Web服务器提交UID和用户密码
当在PC机或手提电脑上打开浏览器连接系统网址时,Web服务器如果发现没有进行身份认证,将允许用户下载身份认证页面(同时下载服务商加密公钥证书),提示用户输入用户识别编号UID和用户密码。用户确认身份认证页面后就可将UID和经服务商加密公钥加密后的用户密码一起提交给Web服务器。
4.6.2以Access-Request包的形式向认证服务器提交UID和用户密码
Web服务器将UID和用户密码封装成Access-Request包,并提交给认证服务器,然后等待认证服务器的响应。如果一段时间后没有响应,可反复发送一定次数。
4.6.3认证服务器验证UID和用户密码
认证服务器首先解出用户密码,再利用单向加密公式计算后与用户信息数据库中的密码进行比对。如果不一致就向Web服务器返回Access-Reject包。如果一致,认证服务器将生成一个随机数(超过一定位数,如8位以上),并向Web服务器返回Access-Challenge包。
4.6.4对挑战进行回应
如果Web服务器收到Access-Challenge包,将向PC机或手提电脑下载挑战页面。页面上有挑战数字,可提示用户按挑战数字重复输入一遍,或者不要求用户再按键输入。用户确认挑战页面后将经服务商加密公钥加密后的挑战数字提交给Web服务器,Web服务器再将它封装成Access-Request包并提交给认证服务器。
4.6.5认证服务器验证挑战回应结果
认证服务器收到挑战回应后,找出私钥,对加密结果进行解密,并与实际的挑战数字进行比较。如果不一致就向Web服务器返回Access-Reject包。如果一致,将根据用户识别编号UID从用户信息数据库中读取该用户的各种应用访问权限,并对用户连网信息进行注册登记,然后向Web服务器返回Access-Accept包。
4.6.6建立访问控制表并配置系统应用页面
如果Web服务器收到Access-Accept包,将分别在Web服务器上和PC机或手提电脑上为用户建立应用访问控制表(一般使用Cookie),并对系统一级应用页面进行配置,然后下载到PC机或手提电脑上。为了保证用户及访问权限的后续有效性,可对用户信息、环境信息、访问控制信息并连同内部密码进行MD5计算,并将计算结果也保存下来,方便以后随时验证。如可采用以下公式进行计算:MD5(用户识别编号UID+密码串一+挑战随机数+IP地址+密码串二+访问控制表)。
4.6.7用户会话结束
当Web服务器发现用户会话结束时,将向认证服务器发送Access-Request包,请求认证服务器对相应用户进行连网注销登记。
4.7认证协议设计
参照RADIUS协议的基本框架模式,但根据本系统的实际应用需求进行设计。
4.7.1介绍
客户/服务器模型
根据身份认证的不同情况,认证客户可能是Wi-Fi AP机、安装有系统认证客户端软件的PC机(或手提电脑)、Web服务器等。
灵活性
为了拓展应用,给用户使用提供方便,根据使用方式考虑了5种不同的认证情况,并在认证协议层进行了充分协调和统一。
安全性
系统既有物理上天然开放的无线网络,还有连接无限包罗万象的互联网,同时还要考虑多种不同的使用方式,安全压力非常之大。考虑到本系统要提供基础的PKI服务,而且在安全消息传输过程当中也需要签名和加密,因此本系统将身份认证、安全消息传输、PKI服务的安全方案统一起来,对外可提供一致的安全接口,对内能简化安全开发和安全管理。
系统既提供了基于Wi-Fi用户机用户证书的安全证书认证模式,也提供了基于用户名(UID)和用户密码的简单口令认证模式,并且都采用了挑战/应答方法进行安全增强,挑战数字和用户密码采用加密公钥进行加密。可限制只有Wi-Fi用户机才能设置和修改用户密码。
采用UDP传输协议
与RADIUS协议一样,也采用UDP传输协议在认证客户和认证服务器之间传输数据包。
4.7.2认证协议包格式
采用RADIUS协议的包格式(RFC 2138,Packet Format),UDP目标端口可选用相同的1812,也可分配一个新的端口号。Identifier,Request Authenticator,ResponseAuthenticator都使用同样的生成和计算规则。
4.7.3认证协议包类型
由包的第一个字节代码域来确定包的类型,采用RADIUS协议一样的名称和格式(RFC 2138,Packet Types)。
4.7.3.1 Access-Request
当用户登录(Login)或者登出(Logout)系统时,或者挑战应答(Challenge-Response)时,由认证客户向服务器发送Access-Request包(代码域设置为1)。
Access-Request共有的属性有:认证客户类型Auth-Client-Type,包括Wi-Fi AP机、安装有系统认证客户端软件的PC机(或手提电脑)、Web服务器等;服务类型Service-Type,包括用户证书登录User Ticket Login、用户口令登录User PasswordLogin、挑战应答Challenge-Response、用户登出User Logout;认证客户IP地址Auth-Client-IP-Address;用户IP地址User-IP-Address;用户名User-Name(用户识别编号UID);用户口令User-Password。
用户证书登录(User Ticket Login)Access-Request
将用户证书中的各项内容(服务商加密公钥除外)分别以属性形式封装在Access-Request当中,属性User-Name使用用户识别编号UID,属性User-Password使用产品批次(也采用RADIUS协议一样的变换隐藏方式),用户证书的其它内容详见后面的属性说明。
如果认证客户是Wi-Fi AP机,还要包括属性Wi-Fi AP位置Wi-Fi-AP-Position。用户口令登录(User Password Login)Access-Request
属性User-Name使用用户识别编号UID,属性User-Password使用用户密码(先用服务商加密公钥加密,然后再采用RADIUS协议一样的变换隐藏方式)。
用户登出(User Logout)Access-Request
属性User-Name使用用户识别编号UID。认证服务器生成的挑战随机数在整个会话期间一直在认证客户和认证服务器上保持,此时作为属性User-Password随包提交(采用RADIUS协议一样的变换隐藏方式)。
用户挑战应答(Challenge-Response)Access-Request
属性User-Name使用用户识别编号UID,属性User-Password使用挑战响应(先用服务商加密公钥对挑战数字进行加密,然后再采用RADIUS协议一样的变换隐藏方式),属性State(保持与原来的Access-Challenge包相同)。
4.7.3.2 Access-Accept
当认证服务器接受认证请求时,将向认证客户返回Access-Accept包(代码域设置为2),并将用户各种应用权限以属性形式封装在包当中。
包括的属性有:服务类型Service-Type;回应信息Reply-Message;会话时限Session-Timeout;空闲时限Idle-Timeout;用户访问控制User-Access-Control(该属性可以有很多个实例,一个实例说明一种应用访问控制,详细格式定义见属性说明)。
4.7.3.3 Access-Reject
当收到的属性值无法接受,或者签名验证不一致,或者比对用户密码不一致,或者挑战验证不成功,认证服务器都将向认证客户返回Access-Reject包(代码域设置为3)。可包括属性回应信息Reply-Message,以向用户提示拒绝原因。
4.7.3.4 Access-Challenge
当用户证书或者用户密码经认证服务器确认通过后,认证服务器将生成一随机数,并向认证客户发送Access-Challenge包(代码域设置为11)。认证客户将挑战数字交给用户确认和加密处理,然后再通过Access-Request包将挑战结果传给认证服务器。在整个会话期间,挑战随机数将在认证客户和认证服务器上保持。
包括的属性有:回应信息Reply-Message;状态State(Magic Cookie,放上挑战随机数);会话时限Session-Timeout;空闲时限Idle-Timeout。
4.7.4属性
属性使用Type-Length-Value三元格式进行定义,如下所示。
1字节 |
1字节 |
0-253字节 |
Type |
Length |
Value |
Type
Type域占一个字节。参照RADIUS协议,根据需要调整如下。
1 User-Name |
2 User-Password |
3 Auth-Client-Type |
4 Auth-Client-IP-Address |
5 User-IP-Address |
6 Service-Type |
7 Wi-Fi-AP-Position |
8 MAC-Address |
9 SSID |
10 Producer |
11 Soft-Version |
12 Service-Provider-Signature |
17 (unassigned) |
18 Reply-Message |
24 State |
26 User-Access-Control |
27 Session-Timeout |
28 Idle-Timeout |
Length
Length域占一个字节,指示属性总的字节长度(包括Type域、Length域和Value域在内)。如果收到的Access-Request包中有属性其Length无效,则应该发送Access-Reject包;如果收到的Access-Accept、Access-Reject或Access-Challenge包中有属性其Length无效,则必须当作Access-Reject包或者直接丢弃。
Value
Value域为0个或多个字节,为属性的具体内容,其格式和长度由Type域及Length域确定。除了RADIUS协议的string、address、integer和time四种数据类型(RFC2138),另增加数据类型physicaladdress(48bit,6字节,第一个字节为最高有效字节)。
4.7.4.1 User-Name
待认证的用户名,本系统为用户识别编号UID,仅在Access-Request包中使用。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
11字节以上 |
Type |
Length |
String... |
Type=1;Length>=13
String:本系统为用户识别编号UID,是超过11位的数字串。
4.7.4.2 User-Password
仅在Access-Request包中使用,用户证书认证时是产品批次,用户口令认证时是经服务商加密公钥加密的用户密码,用户登出时是会话期间一直保持的挑战随机数,用户挑战应答时是经服务商加密公钥加密的挑战数字。随包发送时,再采用RADIUS协议一样的方式进行变换隐藏(RFC 21385.2)。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
16-128字节 |
Type |
Length |
String... |
Type=2;Length>=18,<=130;String 16到128字节长
4.7.4.3 Auth-Client-Type
认证客户类型,仅在Access-Request包中使用。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
4字节 |
Type |
Length |
Value |
Type=3;Length=6
Value:4字节整数。
1 Wi-Fi AP机
PC机或手提电脑(安装有系统认证客户端软件)
3 Web服务器
4.7.4.4 Auth-Client-IP-Address
认证客户IP地址,仅在Access-Request包中使用。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
4字节 |
Type |
Length |
Address |
Type=4;Length=6;Address:4字节地址。
4.7.4.5 User-IP-Address
用户IP地址,仅在Access-Request包中使用。当用户通过Wi-Fi AP机或者Web服务器进行身份认证时,用户与认证客户之间是通过无线或者有线网络进行连接,用户有自己的IP地址,需包括在Access-Request包属性当中。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
4字节 |
Type |
Length |
Address |
Type=5;Length=6;Address:4字节地址。
4.7.4.6 Service-Type
用户请求的,或者服务器将提供的服务类型。在Access-Request包和Access-Accept包中都可以用到。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
4字节 |
Type |
Length |
Value |
Type=6;Length=6
Value:4字节整数。
1 User Ticket Login(用户证书登录)
2 User Password Login(用户口令登录)
3 User Logout(用户登出)
4 Challenge-Response(挑战应答)
4.7.4.7 Wi-Fi-AP-Position
Wi-Fi AP机所在位置,仅在Access-Request包中使用(且认证客户必须为Wi-Fi AP机)。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
12字节 |
Type |
Length |
String... |
Type=7;Length=14
String:12位数字串,包括国家(3).城市(3).地段(4).热点(2)。
4.7.4.8 MAC-Address
Wi-Fi用户机MAC地址,仅在用户证书登录Access-Request包中使用。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
6字节 |
Type |
Length |
PhysicalAddress |
Type=8;Length=8;PhysicalAddress:48bit,6字节,物理地址。
4.7.4.9 SSID
Wi-Fi网络名称,本系统作为服务商名称,用来区分不同的Wi-Fi接入服务和系统服务提供商,仅在用户证书登录Access-Request包中使用。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
1字节以上 |
Type |
Length |
String... |
Type=9;Length>=3
String:一个或多个字节,限定为字母数字串或可打印字符串。
4.7.4.10 Producer
Wi-Fi用户机生产商,仅在用户证书登录Access-Request包中使用。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
1字节以上 |
Type |
Length |
String... |
Type=10;Length>=3
String:一个或多个字节,限定为数字串或字母数字串或可打印字符串。
4.7.4.11 Soft-Version
Wi-Fi用户机软件版本,仅在用户证书登录Access-Request包中使用。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
1字节以上 |
Type |
Length |
String... |
Type=11;Length>=3
String:一个或多个字节,由系统开发者来设定,为可打印字符串。
4.7.4.12 Service-Provider-Signature
服务商对Wi-Fi用户机用户证书的签名,仅在用户证书登录Access-Request包中使用。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
16字节 |
Type |
Length |
String... |
Type=12;Length=18(选用不同的签名算法时可能不一样)
String:长度由选择的签名算法来决定,如选用MD5计算摘要,再用RSA加密摘要,则为128bit,16字节。
4.7.4.13 Reply-Message
同RADIUS协议(RFC 2138 5.18)。
4.7.4.14 State
认证服务器向客户发送的Access-Challenge包中包含该属性,而且要随应答挑战的Access-Request包从客户原样发回给服务器。设置为认证服务器所生成的随机数。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
8字节 |
Type |
Length |
String... |
Type=24;Length=10(不同需要下可能不一样)
String
长度应根据需要选定,如果要求用户按键响应,则不能过长(如6位数字,6字节);如果不要求用户按键而是自动响应(也利用了用户机公钥进行加密),则可长一点(如8位数字,8字节)。
4.7.4.15 User-Access-Control
用户访问控制,仅在Access-Accept包中使用。每一种应用服务需对应一项访问控制,因此同一包中可有0个到多个属性实例。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
4字节 |
4字节 |
4字节 |
4字节 |
10字节 |
12字节 |
Type |
Length |
App-Id |
AC-Type |
Access-Control |
Time-Limit |
Corp-Id |
AP-Limit |
Type=26;Length>=18(Corp-Id和AP-Limit不一定都有)
App-Id:应用编号,32bit整数,由系统服务商分配。
AC-Type
访问控制类型,32bit整数,由系统服务商根据应用设置,包括:
1 integer-based role(整数角色)
2 bit-or-based role(位或角色)
3 integer-based grade authority(整数分级权限)
4 integer-based module authority(整数模块权限)
5 bit-or-based module authority(位或模块权限)
Access-Control
访问控制,32bit整数,由应用管理员根据应用访问控制规则具体设置。
Time-Limit:应用服务到期时间,32bit time。
Corp-Id:如果是针对企业的应用,需加上企业识别编号,直接采用企业群组识别编号GID。
AP-Limit:如果应用要进行区域限制,则需给出Wi-Fi AP具体位置。
4.7.4.16 Session-Timeout
提供给用户的会话最大秒数,或者挑战应答过程的最大等待秒数,用在认证服务器发给客户的Access-Accept包或者Access-Challenge包。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
4字节 |
Type |
Length |
Value |
Type=27;Length=6;Value:4字节整数。
4.7.4.17 Idle-Timeout
在会话或挑战应答过程中,允许用户空闲连接的最大连续秒数,用在认证服务器发给客户的Access-Accept包或者Access-Challenge包。属性格式如下所示,所有域从左到右进行传送。
1字节 |
1字节 |
4字节 |
Type |
Length |
Value |
Type=28;Length=6;Value:4字节整数。
4.7.4.18属性表
下表为不同包中出现哪些属性以及出现数量提供了一个指南。
Request |
Accept |
Reject |
Chal lenge |
# |
Attribute |
11110-110-10-10-10-10-10-100-1000Request |
0000010000000+0-10+0-10-1Accept |
0000000000000+0000Reject |
0000000000000+0-100-10-1Chal lenge |
1234567891011121824262728# |
User-NameUser-PasswordAuth-Client-TypeAuth-Client-IP-AddressUser-IP-AddressService-TypeWi-Fi-AP-PositionMAC-AddressSSIDProducerSoft-VersionService-Provider-SignatureReply-MessageStateUser-Access-ControlSession-TimeoutIdle-TimeoutAttribute |
以下是对上表表格内容含义的定义:
0 该属性一定不会在包中出现。
0+ 该属性可能在包中出现0或多个实例。
0-1 该属性可能在包中出现0或一个实例。
1 该属性必定会在包中出现一个实例。
4.8访问控制设计
为了既能在统一规则下管理系统所有应用服务的权限,又能兼顾不同系统应用服务在访问控制方面的不同要求,特进行以下设计。
4.8.1系统应用服务统一编号
使用32bit无符号整数,可从1到4294967295,由系统服务商集中分配和注册登记。常用服务还可统一设定成某个编号。
4.8.2访问控制类型
共有五种访问控制类型,每种系统应用服务可选择其中一种,并且要在系统应用条目下进行登记。
1 integer-based role(整数角色)
一级访问控制是通过一个32bit无符号整数,其中每个数表示一种独立角色。系统身份认证时只是获取用户角色,用户进入到相关应用服务时再根据角色获取具体的权限。
整数角色只是对外的一个接口,用户角色的设定,角色本身的定义,角色与权限的对应关系,都直接在应用服务中实现。这种访问控制类型一般用在权限比较细比较多的场合,应用服务内部的权限管理可如下设计:将权限区分为模块级和操作级,模块级用32bit无符号整数,标记不同的应用模块(或对象),操作级也用32bit无符号整数,但按位标记操作权限(每个模块最多32种操作权限),设置角色模块操作权限时再位或相加。用户、应用服务、角色、模块和操作之间的关系如图11所示。
2 bit-or-based role(位或角色)
一级访问控制是通过一个32bit无符号整数,其中每一位表示一种独立角色,因此最多能定义32种角色。设定用户角色时,可以位或相加,故可为一个用户设定多重角色。系统身份认证时只是获取用户角色,用户进入到相关应用服务时再根据角色获取具体的权限。
位或角色只是对外的一个接口,用户角色的设定,角色本身的定义,角色与权限的对应关系,都直接在应用服务中实现。这种访问控制类型一般用在用户需要多重角色且权限比较细比较多的场合,应用服务内部的权限管理可如下设计:
将权限区分为模块级和操作级,模块级用32bit无符号整数,标记不同的应用模块(或对象),操作级也用32bit无符号整数,但按位标记操作权限(每个模块最多32种操作权限),设置角色模块操作权限时再位或相加。用户、应用服务、角色、模块和操作之间的关系如图12所示。
3 integer-based grade authority(整数分级权限)
访问控制是通过一个32bit无符号整数,其中每个整数表示一种权限等级,一般数字越大等级越高权限越大,高等级用户享有该级别及以下所有级别的权限。
一般用在权限比较确定,权限等级明显,权限不需要分层管理的场合。系统身份认证时将直接获取用户权限。用户、应用服务、权限等级、模块和操作之间的关系如图13所示。
4 integer-based module authority(整数模块权限)
访问控制是通过一个32bit无符号整数,其中一个整数表示一个应用模块(或对象),或一种服务。模块权限不分等级。一般用在权限比较确定,权限之间互相排斥,权限不需要分层管理的场合。系统身份认证时将直接获取用户权限。用户、应用服务、模块权限、模块(或服务)和操作之间的关系如图14所示。
5 bit-or-based module authority(位或模块权限)
访问控制是通过一个32bit无符号整数,其中每一位(bit)表示一个应用模块(或对象),或一种服务,因此最多能定义32种模块或服务。为用户设定权限时,可以位或相加,故一个用户可操作多个模块或服务。一般用在权限比较少而且确定,同一用户可能需要多项权限,权限不需要分层管理的场合。系统身份认证时将直接获取用户权限。用户、应用服务、模块权限、模块(或服务)和操作之间的关系如图15所示。
4.8.3企业应用服务
如果提供的是企业应用服务,当以实体群组进行登记,并为企业分配一个群组识别编号GID,其他用户要作为企业员工使用应用服务时,则应在登记访问控制权限时连上企业用户群组识别编号(GID)。
4.8.4应用服务访问区域限制
对企业考勤登记、小区物业管理等应用服务,相关用户只能在限定的热点区域内才能使用,因此在设置用户访问控制权限时应给出Wi-Fi AP机具体位置,以指明用户可操作的区域。
五、无线消息传输
用户之间的信息交流要通过Wi-Fi用户机、Wi-Fi AP机和应用服务器之间的通信来实现,而本系统则把这些通信统一抽象为无线消息传输,即在消息(message)层面对通信内容进行封装,然后将消息发送给通信的另一方。
5.1基于应用服务器的请求-响应消息传输模式(如图16所示)
Wi-Fi用户机通过Wi-Fi AP机向应用服务器提出请求(request),应用服务器再根据用户请求给出不同响应(response)。典型的客户/服务器模式,通信传输以TCP协议为基础,可以分配一个独立的应用服务端口。Wi-FiAP机作为用户与服务器之间的代理(proxy),不仅对用户应用访问操作进行控制,而且为公共信息下载提供缓存空间(cache)和缓存控制。类似于HTTP协议,后面将参照该协议进行具体设计。
5.2点到点(P2P)消息传输模式(如图17所示)
Wi-Fi用户机之间通过一个Wi-FiAP机(在同一个AP机通信区域内)或两个Wi-Fi AP机直接传送消息,或者应用服务器通过Wi-Fi AP机向单个Wi-Fi用户机发送消息,都使用这种模式。点到点传输一般采用UDP协议,如果实时性要求不高但可靠性有特别要求,也可采用TCP协议。当一个用户要向另一个用户发送消息时,先向应用服务器请求获取对方在线情况、对方IP地址、所在区域Wi-Fi AP机位置及IP地址等信息。如果对方不在线,则将消息发给应用服务器,以后用户上线时可查询或者由服务器转发。如果对方在线,确认一个对方的端口之后,加上对方IP地址,彼此就可以建立直接连接,以后就可以在此连接上互相传送消息和进行消息应答。Wi-Fi AP机主要作为消息传输代理(proxy)。
5.3按地域广播消息传输模式(如图18所示)
当用户要向特定区域的用户广播消息时,先向应用服务器提出广播请求,由服务器将消息广播到该区域内的所有Wi-Fi AP机上(区域广播),再由Wi-Fi AP机广播到在其无线通信范围内的所有Wi-Fi用户机上(AP广播)。应用服务器向Wi-Fi AP机广播时,是根据区域要求找出Wi-Fi AP机并逐一发送消息,一般采用UDP协议进行传输。而Wi-Fi AP机与其无线通信范围内的所有Wi-Fi用户机则是处于同一个物理网络,可以直接进行网内广播。此种模式下Wi-Fi AP机充当网关(gateway)。
5.4群组消息传输模式(如图19所示)
系统内可建立群组关系(可以是实体的,如企业或团体,也可以是虚拟的),用户可以属于一个或多个群组。要启动群组通信,先由管理用户向应用服务器提出请求,对群组通信进行初始化。启动之后,当一个用户要向群组内其它用户发送消息时,先将消息发送到服务器上,再由服务器逐一转发给其它用户。向服务器发送消息,采用request-response模式,TCP传输协议。服务器转发消息,采用命令/应答模式,TCP或UDP传输协议。Wi-Fi AP机作为消息传输代理(proxy)。
5.5请求-响应无线消息传输协议(Request-Response Wireless Message TransferProtocol,RRWMTP)
类似于HTTP协议(RFC 2616),但根据本系统需要做了简化和修改。
5.5.1统一资源标识符(URI)
倾向于标识目标应用及相关资源,格式如下:
rrwmtp_URL=″rrwmtp:″″//″host[″:″port][abs_path[″?″query]]
目标应用作为域(domain)直接包含在host当中,port为分配给该服务的端口号(不给出则用默认的),abs_path给定资源分类、目录及文件,query给出资源查询参数。host当中的应用域名称要与用户访问控制部分的应用服务管理统一起来,并建立系统级的应用信息表。
5.5.2 RRWMTP消息
基本框架与HTTP消息相同(RFC 2616,4 HTTP Message)。general-header部分保留Cache-Control,Date,Pragma,Transfer-Encoding,Via,Warning等字段。general-header部分另外增加以下字段:
State
放上用户认证过程中的State属性值(挑战随机数),在整个会话过程中一直保存在用户机和服务器上,生成消息时直接填上,收到消息时再与保存的内容进行比较,如果一致则接收,如果不一致则舍弃并报告出错。
Message-From:发送本消息的最初用户,使用其识别编号UID。
Message-To:接收本消息的最终目标用户,使用其识别编号UID。
5.5.3 Request(请求)
基本框架与HTTP相同(RFC 2616,5 Request)。Request方法保留GET,POST,PUT,DELETE。request-header部分保留Accept,Accept-Charset,Accept-Encoding,Accept-Language,Host,User-Agent等字段。request-header部分另外增加以下字段:
AP-Position
传送用户请求的Wi-FiAP机的位置信息。
5.5.4 Response(响应)
基本框架与HTTP相同(RFC 2616,6 Response)。response-header部分保留Age,Location,Retry-After,Server,Vary等字段。增加以下状态码:
“430”:State Error,State出错,与保存的内容不一致。
“431”:Message-From Error,消息发送源用户不存在。
“432”:Message-To Error,消息接收目标用户不存在。
“433”:AP-Position Error,Wi-Fi AP机位置信息出错。
“434”:Signature Error,用户签名出错,验证时不一致。
5.5.5 Entity(消息体)
基本框架与HTTP相同(RFC 2616,7 Entity)。entity-header部分保留Allow,Content-Encoding,Content-Language,Content-Length,Content-Range,Content-Type,Expires,Last-Modified等字段。entity-header部分另外增加以下字段:
User-Signature
发送本消息用户的签名,验证签名时要使用该用户的脱密公钥。签名是对最原始消息,应在消息体加密和Content-Encoding之前进行。可以没有签名,不给出本字段即表示没有签名。
Content-Encrypt-Key
消息体加密密码。用户request消息时如果要求保密,Wi-Fi用户机将随机生成一密码串,并使用该密码串对消息内容进行对称加密,然后再使用用户证书中的服务商加密公钥对密码串进行非对称加密,其结果作为Content-Encrypt-Key,服务器收到消息后用解密私钥对Content-Encrypt-Key进行解密可得到明文密码,接下来再用明文密码解密消息内容。服务器response消息时如果要求保密,当消息来自别的用户且消息内容还是以加密形式暂存服务器上时,只需使用消息接收目标用户的加密公钥对明文密码进行非对称加密,其结果作为Content-Encrypt-Key;而当消息由服务器直接产生时,则由服务器随机生成一密码串,用它对消息进行对称加密,再使用消息接收目标用户的加密公钥对密码串进行非对称加密,其结果作为Content-Encrypt-Key;Wi-Fi用户收到消息时使用解密私钥对Content-Encrypt-Key进行解密得到明文密码,接下来再用明文密码解密消息内容。
如果消息既要求加密也要求签名,则签名应在加密之前进行。如果消息体有加密和Content-Encoding,加密应在Content-Encoding之后,即实际的消息体是按以下三层模型依顺序进行编码变换:
entity-body:=Content-Encrypt-Key(Content-Encoding(Content-Type(data)))
当没有Content-Encrypt-Key时表示消息内容没有加密。
Signature-Key-Type
发送本消息用户的签名密钥类型。用户可能在不同的情况下使用本系统,如带有Wi-Fi用户机,或不连Wi-Fi用户机的PC机或手提电脑(有特别客户端软件,或通过通用浏览器)。为了安全,每种情况下用户应有一套不同的签名和加密密钥对,私钥保存在用户手上,公钥则分别以证书形式存放在用户信息数据库中。
具体包括:
1 Wi-Fi用户机专用签名
2 特别客户端软件专用签名(不连Wi-Fi用户机)
Encrypt-Key-Type
本消息接收者的加密密钥类型。如果发送者是用户,接收者是服务器,将根据发送用户情况使用服务商的相应加密公钥加密消息。如果发送者是服务器,接收者是用户,服务器将根据接收用户情况使用接收者的相应加密公钥加密消息。
如果消息传输是用户到用户,发送消息时将根据对方情况使用对方相应加密公钥进行加密。包括:
1 Wi-Fi用户机专用加密密钥
2 特别客户端软件专用加密密钥(不连Wi-Fi用户机)
3 通用浏览器专用加密密钥(不连Wi-Fi用户机)
5.5.6 Wi-Fi AP机的作用
作为Wi-Fi用户机和应用服务器之间的代理(proxy),发挥以下作用:
为用户提供应用访问控制
用户身份认证成功之后,将在Wi-FiAP机上建立相应的应用访问控制表,以后用户与服务器之间进行消息通信时要受访问控制表限制。
为信息发布搜索交流应用提供区域位置信息
整个系统的信息发布搜索交流应用是按地域进行层次划分的,而划分的依据则是Wi-Fi AP机的位置信息,用户与服务器进行消息通信时将自动以Wi-Fi AP机位置信息作为参数。
为消息响应提供缓存(cache)
类似于HTTP协议的响应缓存机制(caching)主要通过Wi-Fi AP机来实现,由于系统信息按区域进行划分,区域公共信息下载时可在Wi-Fi AP机cache中保留副本,以后有用户通过AP机请求相同信息时,AP机先检查自己的cache,如果存在则直接发送给用户。
5.6点到点无线消息传输协议(P2P Wireless Message Transfer Protocol,P2PWMTP)参照HTTP协议(RFC 2616)和SIP协议(RFC 3261,RFC 3428),并与上面设计的RRWMTP协议进行融合和统一。
5.6.1统一资源标识符(URI)
采用邮件地址的形式,格式如下:
p2pwmtp:user@host:port;uri-parameters?headers
user为用户识别编号UID。可能有不同的应用服务采用这种消息传输模式,因此将目标应用作为域(domain)直接包含在host当中,port为分配给该服务的端口号(不给出则用默认的)。
5.6.2会话邀请和消息转发
用户要向另一用户发送消息时,先向应用服务器提出请求(request),URI为p2pwmtp URI格式,方法为INVITE。应用服务器然后将对方在线情况和IP地址等信息通过消息响应(response)回送给用户。如果对方不在线,则将消息通过requestMESSAGE方法发给应用服务器,以后对方上线时可查询或者由服务器转发。用户结束消息发送时则提交request BYE方法。此时采用的仍是request-response模式,消息基本结构与RRWMTP相同,但增加了INVITE、MESSAGE、BYE三个request方法。
5.6.3用户点到点(P2P)消息传输
如果用户通过应用服务器获知想通信的另一方也在线,彼此就可以建立直接通信连接,以后就可以在此连接上互相通过命令/应答方式传送消息。传送消息命令由命令行(Command-Line)、general-header、entity-header和entity-body几部分组成,命令行格式如下:
Command-Line=Command SP P2PWMTP-URI SP P2PWMTP-Version CRLFCommand包括MESSAGE和BYE。
general-header、entity-header、entity-body与RRWMTP基本一致。
消息接收者应答时只有一状态行(Status-Line),格式如下:
Status-Line=P2PWMTP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Code包括:
“200”:OK,消息传送成功,正常接收。
“400”:Bad Command,命令或命令参数出错。
“408”:Command Time-out,消息传送超时。
“413”:Entity Too Large,消息体超长。
“415”:Unsupported Media Type,不支持的媒体类型。
“430”:State Error,State出错,与保存的内容不一致。
“434”:Signature Error
签名出错,找不到用户或其脱密公钥,或者验证时不一致。
“480”:Temporarily Unavailable,表示暂时离开或勿打扰。
“489”:Log Out,用户已离线。
5.6.4消息数字签名和加密
点到点消息传输发送用户也可以进行数字签名,发送时也可以选择加密。如果对方不在线,消息要通过服务器转发,加密时可使用服务商的加密公钥(本地没下载对方的加密公钥证书)或对方的加密公钥。如果对方在线,则应向服务器请求下载对方的加密公钥证书,并用对方的加密公钥加密。接收消息时如果有发送方的数字签名,则应向服务器请求下载发送方的签名脱密公钥证书以验证对方签名。签名和加密的其它处理与RRWMTP协议基本相同,但entity-header部分要增加以下字段:
Public-Key-User(通过服务器转发时使用)
加密公钥用户UID。如果消息体有加密,但不是使用服务商的加密公钥,而是直接使用接收用户的加密公钥,则通过该字段给出。
5.6.5 Wi-Fi AP机的作用
点到点用户传输消息时可能通过一个或两个Wi-Fi AP机,起代理(proxy)作用,主要是为用户提供应用访问控制。如果两个用户通过服务器确认在同一个AP机通信区域内,此时应能直接建立网内通信连接。
5.7区域广播无线消息传输协议(District Broadcast Wireless Message Transfer Protocol,DBWMTP)
协议框架和消息结构与P2PWMTP协议基本相同。
5.7.1统一资源标识符(URI)
采用邮件地址的形式,格式如下:
dbwmtp:district@host:port;uri-parameters?headers
district为区域信息,格式为国家.城市.地段.热点。可能有不同的应用服务采用这种消息传输模式,因此将目标应用作为域(domain)直接包含在host当中,port为分配给该服务的端口号(不给出则用默认的)。
5.7.2广播请求
用户要向某区域内用户广播消息时,先向应用服务器提出请求(request),URI为dbwmtp URI格式,方法为BROADCAST。服务器收到广播请求后,对消息进行检查,并核查发送用户权限,如果有问题,将给出适当的Client Error响应(response)。如果没有问题,服务器将生成一个广播编号(系统内唯一),并给出成功response,其response-header部分增加字段Broadcast-ID,通过它向发送用户返回广播编号。接下来服务器广播消息时,也要在其response-header部分加上Broadcast-ID字段。消息基本结构与RRWMTP相同,增加一个BROADCAST request方法,增加一个Broadcast-ID response-header字段,而Message-To字段内容为广播区域信息。
5.7.3区域广播
服务器收到广播请求后,根据区域信息逐一找出区域内的Wi-Fi AP机,建立UDP通信连接,并将消息发送给AP机。
5.7.4AP广播
Wi-Fi AP机收到广播消息后,可利用物理网络广播机制在其通信区域内进行广播,并根据要求将其存放在自己的cache当中。消息中有Cache-Control、Date和Expires三个字段,通过它们可控制AP广播行为。是否重复接收广播在Wi-Fi用户机上自动进行判断,每条广播消息其头部都有Broadcast-ID字段,用户机收到广播消息后,其Broadcast-ID内容缓存一段时间,接收新广播消息时,如果其Broadcast-ID与缓存中的相同,就停止接收,并将其舍弃。
timing-broadcast
Expires到来之前定时广播,为指示定时秒数增加以下Cache-Control指令:
timing-broadcast=delta-seconds。
scaling-broadcast
定数广播,可与定时广播合用,当定数减到0时停止广播,并从cache中删除,为指示广播次数增加以下Cache-Control指令:scaling-broadcast=delta-number。
login-broadcast
Expires到来之前,用户进入AP通信区域登录系统后,AP机就向该用户发送广播消息。与定时广播和定数广播是互斥关系,增加以下Cache-Control指令来标识:login-broadcast。
5.7.5 Wi-Fi AP机的作用
服务器向特定区域广播消息时,先将消息发给区域内的Wi-Fi AP机,再由AP机通过网内广播发给用户,起网关(gateway)作用。用户通过Wi-Fi AP机向服务器请求广播时,则为用户提供应用访问控制。
5.8群组无线消息传输协议(Wide Group Wireless Message Transfer Protocol,WGWMTP)
协议框架和消息结构与P2PWMTP协议基本相同。
5.8.1群组识别编号GID编码设计
可比UID少一位,UID如用11位数字,GID则用10位,格式如下所示,其中服务商编号Service-Provider-Id与UID中的相同。
XXX(3位数字) |
XXXXXXX(7位数字) |
Service-Provider-Id |
Order-Number |
5.8.2统一资源标识符(URI)
采用邮件地址的形式,格式如下:
wgwmtp:group@host:port;uri-parameters?headers
group为群组识别编号GID。可能有不同的应用服务采用这种消息传输模式,因此将目标应用作为域(domain)直接包含在host当中,port为分配给该服务的端口号(不给出则用默认的)。
5.8.3启动群组通信
要启动群组通信,群组管理员先向应用服务器提出请求(request),URI为wgwmtpURI格式,方法为INVITE。服务器然后对请求进行核查,如果通不过,将给出适当的Client Error响应(response)。如果能通过,则统计群组总用户数和在线用户数,并给出成功response,其消息体中包括群组统计结果和当前在线用户清单等信息。接下来服务器还要对群组通信服务进行初始化。管理员要结束群组通信时则提交requestBYE方法。消息基本结构与P2PWMTP相同。
5.8.4发送消息
当一个用户要向群组内其它用户发送消息时,先通过request将消息发送到服务器上,URI为wgwmtp URI格式,方法为MESSAGE,头部Message-To字段内容为GID。服务器将根据情况给出适当response。
5.8.5转发消息
服务器收到群组内用户发来的消息后,要逐一通过命令/应答方式将消息转发给群组内其它在线用户。转发消息由命令行(Command-Line)、general-header、entity-header和entity-body几部分组成,命令行格式如下:
Command-Line=Command SP WGWMTP-URI SP WGWMTP-Version CRLFCommand包括MESSAGE。
general-header、entity-header、entity-body与RRWMTP基本一致。
消息接收者应答时只有一状态行(Status-Line),格式如下:
Status-Line=WGWMTP-Version SP Status-Code SP Reason-Phrase CRLFStatus-Code内容与P2PWMTP的Status-Code相同。
5.8.6消息数字签名和加密
群组消息传输发送用户也可以进行数字签名,发送时也可以选择加密。向服务器请求发送消息时,如果要加密,将直接使用用户证书中的服务商加密公钥。服务器转发消息时,先解密,再换用接收用户的加密公钥加密。接收消息时如果有发送方的数字签名,则应向服务器请求下载发送方的签名脱密公钥证书以验证对方签名。签名和加密的其它处理与RRWMTP协议基本相同。
5.8.7 Wi-Fi AP机的作用
群组消息传输Wi-FiAP机起代理(proxy)作用,主要为用户提供应用访问控制。5.9有线上网带特别客户端软件PC机(连Wi-Fi用户机)的消息传输
发送消息的签名和加密以及接收消息的签名验证和解密,都是提交给Wi-Fi用户机处理。发送消息entity-header部分的Signature-Key-Type设置为1,接收消息要验证对方签名时将根据Signature-Key-Type去下载相应脱密公钥。发送消息entity-header的Encrypt-Key-Type将根据接收方而定,接收消息Encrypt-Key-Type应该为1,交给Wi-Fi用户机解密。
5.9.1请求-响应消息传输
如图20所示,与RRWMTP协议基本相同。request消息体头部字段Encrypt-Key-Type应设置为1。访问控制通过PC机或手提电脑。
5.9.2点到点消息传输
如图21所示,连接Wi-Fi用户机并通过有线上网的PC机(手提电脑)能与另一台有线上网的PC机(手提电脑)或Wi-FiAP机通信区域内的Wi-Fi用户机进行点到点消息传输。采用P2PWMTP协议,发送消息Encrypt-Key-Type根据对方情况而定。访问控制通过PC机或手提电脑。
5.9.3群组消息传输
如图22所示,连接Wi-Fi用户机并通过有线上网的PC机(手提电脑)能与别的有线上网的PC机(手提电脑)或Wi-FiAP机通信区域内的Wi-Fi用户机进行群组通信。采用WGWMTP协议,给服务器发送消息时Encrypt-Key-Type设置为1。访问控制通过PC机或手提电脑。
5.10有线上网带特别客户端软件PC机(不连Wi-Fi用户机)的消息传输
为了安全,用户应另外申请一套不同于Wi-Fi用户机的签名密钥对和加密密钥对,私钥存放在客户端,公钥存放在用户信息数据库中。发送消息entity-header部分的Signature-Key-Type设置为2,接收消息要验证对方签名时将根据Signature-Key-Type去下载相应脱密公钥。发送消息entity-header的Encrypt-Key-Type将根据接收方而定,接收消息Encrypt-Key-Type应该为2。
5.10.1请求-响应消息传输
如图23所示,与RRWMTP协议基本相同。request消息体头部字段Encrypt-Key-Type应设置为2。
5.10.2点到点消息传输
如图24所示,能与另一台有线上网PC机或手提电脑(连或不连Wi-Fi用户机),或者AP机通信区域内的Wi-Fi用户机进行点到点消息传输。采用P2PWMTP协议,发送消息Encrypt-Key-Type根据对方情况而定。
5.10.3群组消息传输
如图25所示,能与别的有线上网的PC机或手提电脑(连或不连Wi-Fi用户机),或者Wi-Fi AP机通信区域内的Wi-Fi用户机进行群组通信。采用WGWMTP协议,给服务器发送消息时Encrypt-Key-Type设置为2。
5.11有线上网使用浏览器PC机(连Wi-Fi用户机)的应用消息传输
如图26所示,应用服务建立在客户端浏览器和Web服务器之上,采用HTTP传输协议和request-response模式。客户端发送request消息的签名和加密,接收response消息的签名验证和解密,都交给Wi-Fi用户机处理,处理方式与RRWMTP协议相同。为保证消息传输安全,有三种方案。
5.11.1在普通HTTP协议基础上通过编程实现
采用HTTP协议(RFC 2616),最常用的Web服务器和浏览器,通过应用编程实现签名和加密,签名验证和解密。即如果消息体需要签名和加密,可在签名和加密之后按约定格式将用户签名、加密密钥、签名密钥类型、加密密钥类型、消息来源、消息去向连同加密后的消息合成新的消息体进行传输。如提交request消息时,可将上述内容放在隐藏域中;生成response消息时,可作为脚本变量,也可作为隐藏域。
5.11.2采用Secure HTTP (S-HTTP)协议
Secure HTTP(RFC 2660)协议定义了签名和加密等安全机制,只需按其要求定义好相应Header字段即可,但要求浏览器和Web服务器能够支持。如使用S-HTTP(Unencapsulated)Headers,Content-Privacy-Domain设置为CMS,则消息体由不同类型的内容序列构成,包括Data、SignedData、EnvelopedData、DigestedData、EncryptedData等类型。
5.11.3应用建立在HTTP/TLS之上
TLS协议(RFC 2246)通过客户和服务器之间的握手协议互相认证,互相交换证书、密钥、加密算法等,从而在客户和服务器之间建立起可安全传输应用数据的会话连接。而HTTP over TLS(RFC 2818)为在TLS协议基础上设计HTTP做了说明。具体到本系统,客户和服务器都已掌握对方的公钥和证书,认证和加密算法也事先确定,在握手协议中互相认证和交换随机数后,双方根据pre_master_secret计算出master_secret(RFC 2246 8.1),以后传输应用数据时就使用master_secret加密和解密。TLS协议没有消息签名方面的设计,如果要考虑签名,可在设计应用软件时将消息签名作为应用数据的一部分。
5.12有线上网使用浏览器PC机(不连Wi-Fi用户机)的应用消息传输
如图27所示,用户通过浏览器和Web服务器使用系统应用服务,但没带Wi-Fi用户机,无法用私钥签名,也没有私钥解密用自己公钥加密过的消息,因此无法实现需要私钥签名和解密的应用服务,安全方面受到限制。针对这种应用情况,服务商要生成一对签名密钥和一对加密密钥,公钥以证书形式对外发布,用户可通过浏览器下载。客户端提交request消息时,如果需要加密,先随机生成一密码串,并用它对消息进行对称加密,然后再用服务商加密公钥加密该密码串,与加密过的消息组成新的消息体一同传输。Web服务器如果收到加密过的消息,先用私钥解密出密码串,再用密码串解密出消息,生成response消息时,也要使用相同的密码串进行对称加密。具体实现时,也有三种方案。
5.12.1在普通HTTP协议基础上通过编程实现
采用普通的HTTP协议(RFC 2616)。提交request消息时,如果有加密,可将加密密钥、加密密钥类型、消息来源、消息去向等内容放在隐藏域中;而response消息加密情况由request消息直接决定。
5.12.2采用Secure HTTP(S-HTTP)协议
使用S-HTTP(Unencapsulated)Headers,Content-Privacy-Domain设置为CMS,消息体包括Data、DigestedData、EncryptedData等内容序列。
5.12.3应用建立在HTTP/TLS之上
在握手协议中客户取得服务商公钥证书,客户和服务器互相认证和交换随机数,然后双方根据pre_master_secret计算出master_secret(RFC 2246 8.1),会话连接期间传输应用数据时使用master_secret加密和解密。
5.13邮件无线传输
系统为用户提供安全的电子邮件服务,邮件地址格式为user@host,其中user为用户识别编号UID,host为服务商邮件服务器主机。邮件传输可以在本系统用户之间,也可以在本系统用户与别的邮件系统用户之间。如图28所示,系统邮件服务部分包括邮件服务器、Wi-Fi用户机和Wi-Fi AP机,邮件服务器提供邮件发送、接收、存储、管理、安全等服务,支持SMTP(RFC 821)、POP3(RFC 1939)、IMAP4(RFC 1730)等标准协议;Wi-Fi用户机则包含邮件发送、接收、管理、安全等用户代理(User Agent)程序,通过Wi-FiAP机连上邮件服务器后,就可发送、接收和管理邮件;AP机起代理(proxy)作用,为用户提供邮件访问控制。
用户发送邮件时可以签名和加密。签名时使用Wi-Fi用户机上的签名私钥(用口令保护),收到其他用户的签名邮件时,如果没有对方的签名验证公钥,将自动从服务器上下载。需要加密时,Wi-Fi用户机将随机生成一密码串,并使用该密码串对邮件进行对称加密,然后再对密码串进行非对称加密(如果有对方公钥就直接使用,如果没有就使用用户证书中的服务商加密公钥,需要标明)。接收方从邮件服务器取加密邮件时,如果是使用服务商加密公钥加密,邮件服务器先找出服务商私钥解密,再找出接收方加密公钥加密,到接收方Wi-Fi用户机上时,直接用机上私钥解密出对称密码串,然后再用密码串解密加密邮件。如果要求邮件同时有签名、压缩和加密,其处理顺序与PGP相同(签名—>压缩—>生成密码串进行对称加密—>对密码串进行非对称加密)。
有了签名和加密,邮件格式将变复杂,具体实现时有两种方案。
5.13.1采用普通的MIME标准结构(RFC 2045,2046)
如果需要签名,将签名作为一个附件(multipart消息体内的一个子消息体,定义为″application/octet-stream″,或者新定义一个x-signature子类型)。如果需要加密,对称加密后的消息作为一个子消息体(定义为″application/octet-stream″,或者新定义一个x-encrypteddata子类型),而用公钥加密后的对称密码串作为另一个子消息体(定义为″application/octet-stream″,或者新定义一个x-encryptkey子类型),并以参数形式标明是使用邮件接收方公钥加密还是使用服务商公钥加密。
5.13.2采用安全的S/MIME标准结构(RFC 3851)
S/MIME在″application/pkcs7-mime″之下通过smime-type参数和附件定义了enveloped-data、signed-data、certs-only、compressed-data等几种消息体,用于承载EnvelopedData、SignedData和CompressedData三种CMS内容类型,因此按其要求生成和封装好相应数据即可。
六、消息传输安全和PKI服务系统设计
本系统综合身份认证、访问控制、应用消息传输、通用PKI服务的需要统一进行安全方面的设计。如图29所示,PKI服务系统包括负责密钥及证书管理的PKI应用服务器和进行密钥备份存放PKI证书的数据库,Wi-Fi用户机可直接通过Wi-Fi AP机请求PKI应用服务,带特别客户端软件的PC机或手提电脑上网后也能直接请求PKI应用服务,而通过浏览器上网的PC机或手提电脑则需通过Web服务器请求PKI应用服务。
6.1 Wi-Fi用户机安全设计
Wi-Fi用户机是标识用户身份的特有凭证,是用户开启系统的钥匙。
6.1.1用户证书
每台Wi-Fi用户机内都有一份自己的用户证书。服务商根据产品批次生成一对签名密钥和一对加密密钥,加密公钥包含在用户证书当中,并用服务商签名私钥对证书进行签名。签名密钥对和加密密钥对都在服务商产品及用户信息数据库中进行备案。
6.1.2用户签名密钥对和加密密钥对
用户可通过Wi-Fi用户机申请自己的签名密钥对和加密密钥对,作为Wi-Fi用户机专用密钥,私钥保存在用户机上,公钥则以X.509证书形式保存在PKI证书库中。用户还可换用新的签名密钥对和加密密钥对,原有的密钥将作废,但解密私钥会以备份形式保存在用户机上,而过期的公钥证书也会在PKI证书库中标记备案。用户还可设置一个口令保护签名私钥,需要签名时,提示用户输入口令,口令正确才能解锁和签名。
6.1.3用户登录密码
用户可能希望在没有Wi-Fi用户机的情况下也能通过特别客户端软件或者通用浏览器使用本系统,为此用户只能通过Wi-Fi用户机开启相关服务,而且必须通过Wi-Fi用户机设置一个用户登录密码。
6.2特别客户端安全设计
用户在没有Wi-Fi用户机的情况下通过特别客户端软件使用本系统。
6.2.1 UID和用户密码
用户使用识别编号UID和用户密码登录系统。服务商专门生成一对签名密钥和一对加密密钥,并在服务商产品及用户信息数据库中进行备案保存。公钥还以X.509证书形式保存在PKI证书库中并对外发布,公钥证书可包含在客户端软件当中,也可随时从服务器上下载。
6.2.2用户签名密钥对和加密密钥对
用户可通过客户端软件申请自己的签名密钥对和加密密钥对,作为特别客户端软件专用密钥,私钥保存在客户端,公钥则以X.509证书形式保存在PKI证书库中。用户还可换用新的签名密钥对和加密密钥对,原有的密钥将作废,但解密私钥会以备份形式保存在客户端,而过期的公钥证书也会在PKI证书库中标记备案。用户还可设置一个口令保护签名私钥,需要签名时,提示用户输入口令,口令正确才能解锁和签名。
6.3通用浏览器安全设计
用户在没有Wi-Fi用户机的情况下通过浏览器使用本系统。
6.3.1 UID和用户密码
用户使用识别编号UID和用户密码登录系统。服务商专门生成一对签名密钥和一对加密密钥,并在服务商产品及用户信息数据库中进行备案保存。公钥还以X.509证书形式保存在PKI证书库中并对外发布,公钥证书可随时从服务器上下载。
6.4消息传输安全设计
无论是Wi-Fi用户机,还是特别客户端,或者通用浏览器,其安全设计的重要目标就是保证消息传输的安全。
6.4.1消息签名
消息发送方可使用Wi-Fi用户机或特别客户端的签名私钥对消息进行签名,消息接收方通过下载对方相应签名脱密公钥验证对方签名。
6.4.2消息加密
需要加密的消息如果是通过Wi-Fi用户机或特别客户端或浏览器发出,首先在发出地点生成随机密码串,并用它对消息进行对称加密,然后再使用服务商加密公钥或接收方加密公钥对随机密码串进行非对称加密。服务器转发消息时,如果对称密码串是用服务商加密公钥加密,先解密,再使用接收方加密公钥加密。服务器直接向用户发送消息时,先生成随机密码串进行对称加密,再使用接收方加密公钥加密。Web服务器响应浏览器加密请求时,直接使用请求客户生成和传递过来的对称密码串进行对称加密。接收到加密消息后,使用接收端相应私钥解密。
6.4.3消息压缩、签名和加密顺序
一般按以下顺序处理:签名—>压缩—>生成密码串进行对称加密—>对密码串进行非对称加密。
6.5安全算法
本系统不对签名或加密的具体算法进行限制,可选用任何安全有效速度快的算法。如对称加密可选用IDEA、DES、RC6、AES等,签名可选用RSA、NIST-DSS等,密码串非对称加密可选用RSA、DH等,压缩可选用gzip等。为了系统的简洁性,每类安全算法一般只选定一种,在Wi-Fi用户机、特别客户端、浏览器和服务器上都支持选定算法。
6.6 PKI服务系统设计
本系统内部的安全设计是以PKI(Public Key Infrastructure Certificate)为基础,因此完全可以遵照PKI的规范(X.509,RFC 3280)对外提供CA服务。PKI证书库中存放每个用户Wi-Fi用户机专用签名脱密公钥证书、特别客户端软件专用签名脱密公钥证书、Wi-Fi用户机专用加密公钥证书、特别客户端软件专用加密公钥证书,还有专门对应Wi-Fi用户机产品批次的服务商签名和加密公钥证书、不连Wi-Fi用户机特别客户端的服务商签名和加密公钥证书、不连Wi-Fi用户机浏览器客户端的服务商签名和加密公钥证书。用户自己生成签名和加密密钥对,并向服务器提交对应公钥,生成标准证书后存放到PKI证书库中。用户还可换用新的签名和加密密钥对,旧的将作废,作废的签名脱密公钥证书还在证书库中保留,但要标出有效使用时间和作废状态,作废的加密公钥证书将在备份后从证书库中删除。系统为用户的解密私钥提供备份和恢复服务。除了提供密钥及证书管理,系统还为外部的系统及应用提供统一的接口。
七、信息层次和信息分类设计
本系统的一个主要应用是为人们提供一个足够灵活方便的信息发布、搜索和交流平台,而信息具有明显的地域层次特性和分类特性。
7.1信息层次设计
7.1.1信息层次(区域位置)编码设计
信息从高到低划分为4个层次,总共用12位数字进行编码,定义信息层次时可用前3位、前6位、前10位或全部12位,格式如下所示。
XXX(3位数字) |
XXX(3位数字) |
XXXX(4位数字) |
XX(2位数字) |
state |
city |
district |
hot area |
国家(地区) |
城市 |
地段 |
热点(信息点) |
7.1.2国家(地区)
表示一个国家或行政管辖相对独立的地区,用3位数字表示,可自行编码,也可借鉴国际长途电话的国家(地区)编号。当某条信息的层次定义是3位数字时,表示该信息可在该国家(地区)范围内检索浏览。
7.1.3城市
表示现实的行政或经济意义上的城市,用3位数字表示,在国家(地区)范围内统一编码,可借鉴国内长途电话的区号。当某条信息的层次定义是6位数字时,表示该信息可在指定城市范围内检索和浏览。
7.1.4地段
表示城市内人口、公共资源、服务设施和人员流动相对集中的区域,如城镇商业中心、商务中心、社区中心和交通中心,用4位数字表示,在城市范围内统一编码,可根据实际情况和需要随时安排、设置和定义,具体包括城市商业街、商业大厦、专业市场、写字楼、车站码头、空港海港、居民小区,还有乡镇集市、村组集会等场所。当某条信息的层次定义是10位数字时,表示该信息只能在指定地段检索和浏览。
7.1.5热点(信息点)
Wi-Fi无线通信的距离有限,Wi-Fi AP机能覆盖的通信范围一般在100m之内,因此一些地段一台Wi-Fi AP机也许无法覆盖,需要多台,如一些大的商业街、商厦、市场、写字楼、车站、空港、居民小区等。用2位数字表示,在地段范围内统一编码,可根据实际情况和需要随时安排、设置和定义。当某条信息的层次定义是12位数字时,表示该信息只有在指定热点(信息点)才能检索和浏览。
7.2信息分类设计
7.2.1信息分类编码设计
将信息区分为大类和细分类,大类用1位数字编码,细分类用2位数字编码,总共是3位数字,格式如下表所示。
X(1位数字) |
XX(2位数字) |
信息大类 |
信息细分类 |
信息大类包括:
1公共信息 2分类信息 3即时信息 4留言信息
5邮件信息 6广告信息 7应用信息
其中即时信息为用户之间进行即时通信和群组通信时的信息,应用信息则为考勤管理、买卖商城、办公及业务管理、小区物业管理等企业应用过程中传递的信息。
7.2.2公共信息分类编码设计
公共信息一般由服务商主动提供,由服务商负责收集、整理和维护,并与具体的区域位置(国家.城市.地段)相对应,分类编码如下:
01 新闻 |
02 天气预报 |
03 交通状况 |
04 旅游景点 |
05 地方特色 |
06 政府公告 |
07 民生公告 |
08 公共交通 |
09 公共服务 |
10 公共设施 |
11 街道马路 |
12 特色店号 |
交通状况一般是对城市主要道路路况、事故拥堵情况的及时通报,公共交通是对所在地段公交换乘线路、地铁线路及站点的跟踪介绍,公共服务包括银行网点、邮局、供气、供水、供电、电信、医院、政府机关、学校等,公共设施包括公厕、建筑物、影剧院、公园、游乐园等。
7.2.3分类信息编码设计
分类信息一般由用户自己发布,发布的区域位置也由用户根据自己的需要选择,并由用户自己负责信息刷新、修改和删除,编码如下:
01 促销活动 |
02 餐饮美食 |
03 房屋地产 |
04 商店门面 |
05 酒吧夜总会 |
06 旧货交易 |
07 招聘 |
08 求职 |
09 征婚 |
10 团购 |
11 产品招商 |
12 寻人启事 |
13 寻物启事 |
14 失物招领 |
15 转让车票 |
16 电影院线 |
17 搬家搬屋 |
18 家政清洁 |
19 装饰装修 |
20 家教 |
21 水电安装 |
22 泥瓦杂工 |
23 通厕通管 |
24 废品收购 |
25 地产经纪 |
26 医疗门诊 |
27 家电维修 |
28 美容美发 |
29 婚纱摄影 |
30 婚礼婚庆 |
31 旅游 |
32 敬老院 |
33 花卉园艺 |
34 快递 |
35 物流货运 |
36 心理咨询 |
37 保健按摩 |
38 桑拿沐足 |
39 名片复印 |
40 印刷排版 |
41 汽车维修 |
42 保险证券 |
43 培训招生 |
44 驾驶驾照 |
45 留学咨询 |
46 票务 |
47 建筑设计 |
48 广告策划 |
49 工商注册 |
50 电脑网络 |
51 软件开发 |
52 管理咨询 |
53 租车 |
54 典当拍卖 |
55 物业管理 |
56 监理 |
57 律师 |
58 会计 |
59 审计 |
60 资产评估 |
61 商标专利 |
62 礼仪公关 |
63 翻译 |
7.3信息层次和信息分类的关系
如表7.3所示,有些信息需要在国家范围检索浏览,有些信息只需在城市范围检索浏览,而更多信息限定到某个地段甚至热点就足够了。当用户持Wi-Fi用户机进入某个热点(Wi-Fi AP机)通信范围内时,能检索和浏览该热点及热点所属的地段、城市、国家(地区)内的公共信息和分类信息,能将自己的分类信息发布到该热点及热点所属的地段、城市、国家(地区),能发送和接收自己的即时信息、留言信息和邮件信息,能操作自己获得了相应操作权限的应用信息。
表7.3 |
国家(地区) |
城市 |
地段 |
热点 |
公共信息 |
新闻 |
√ |
√ |
|
|
天气预报 |
|
√ |
|
|
交通状况 |
|
√ |
|
|
旅游景点 |
|
√ |
√ |
|
地方特色 |
|
√ |
|
|
政府公告 |
√ |
√ |
|
|
民生公告 |
|
√ |
√ |
|
公共交通 |
|
|
√ |
|
公共服务 |
|
|
√ |
|
公共设施 |
|
|
√ |
|
街道马路 |
|
|
√ |
|
特色店号 |
|
|
√ |
|
分类信息 |
√ |
√ |
√ |
√ |
八、软件设计
系统中各项协议和各种功能需要通过各部分软件协同实现。
8.1 Wi-Fi用户机软件设计
如图30所示,Wi-Fi用户机软件包括操作系统、通信传输协议、通信传输安全等底层模块,以及认证处理、USB通信、系统应用等上层程序。考虑到软件功能比较复杂,因此选择在嵌入式操作系统下开发,具体实现时可根据情况及需要来选择,但应与Wi-Fi AP机的选择相同,如μC/OS、μClinux、VxWorks、Palm OS、Windows CE等,都是目前比较流行的嵌入式操作系统。通信传输协议部分既复杂又关键,底层实现Wi-Fi无线通信的物理层和MAC层,支持国际标准的IEEE 802.11系列协议,需要的话还要支持国内强制国家标准;网络层实现TCP/IP协议簇;应用层除了实现HTTP、DHCP、SMTP、POP3、IMAP4等国际标准协议的客户端,还要实现本系统特别设计的RRWMTP、P2PWMTP、DBWMTP、WGWMTP等协议(或客户端)。通信传输安全基础是用户证书、用户签名及解密私钥、下载的签名及加密公钥证书,中间提供密钥生成、私钥管理、公钥证书管理、对称加密(包括生成随机对称密码串),上层则是直接签名、解密、签名脱密验证、公钥非对称加密。认证处理程序配合Wi-FiAP机等认证客户进行身份认证,系统应用程序则以各种通信传输协议为基础,它们根据需要调用安全方面的上层模块。Wi-Fi用户机作为USB功能设备,要支持与USB主机控制器之间的通信。
8.2特别客户端软件设计
用户通过有线上网的PC机(手提电脑)使用系统应用服务,但要在上面安装一套特别客户端软件。如图31所示,特别客户端软件包括通信传输安全、USB主机客户程序、通信传输应用层协议等基础模块,以及系统认证、系统应用等上层程序。当没有连接Wi-Fi用户机时,通信传输安全以客户端自带的签名及解密私钥、签名及加密公钥证书为基础,直接调用客户端安全处理模块。当连接有Wi-Fi用户机时,将通过USB主机客户程序使用Wi-Fi用户机上的安全信息和安全处理功能。需要实现本系统特别设计的认证协议的客户端,成功后建立用户访问控制表。
8.3 Wi-Fi AP机软件设计
Wi-Fi AP机为Wi-Fi用户机接入本系统和互联网提供动态地址分配、通信路由、认证、区域限制、应用协议代理、信息缓存(cache)、应用访问控制等多方面的服务。如图32所示,因软件功能复杂,选择在嵌入式操作系统下开发,通过IEEE 802.11 AP连接Wi-Fi用户机,通过以太网连接有线局域网,通过xDSL(PPPoE)上广域网(互联网)。用户进入AP机通信区域内时,通过DHCP分配一个IP地址,然后作为认证协议客户对用户进行认证,认证成功将在AP机上建立用户访问控制表。AP机为HTTP、SMTP、POP3、IMAP4、RRWMTP、P2PWMTP、WGWMTP等应用层协议提供代理(proxy)服务,并为HTTP、RRWMTP(下载公共信息和分类信息时)提供缓存功能(cache)。AP机为DBWMTP提供网关(gateway)服务,收到区域广播消息后按要求进行AP广播。每台AP机需要设置具体的位置信息,在认证协议和应用层协议(RRWMTP、P2PWMTP、WGWMTP、DBWMTP)中都要用到,在应用访问控制中也可能用到。AP机根据用户访问控制表对应用服务进行具体控制。AP机提供SNMPAgent程序,网络管理站可通过它对AP机参数进行设置和监控。另外,AP机还包含有Web服务器软件(Linux下免费的有miniHTTP、httpd和Apache),互连的其它计算机可通过浏览器设置和监控其参数。
8.4认证服务器软件设计
如图33所示。认证服务器上存有特别客户端及通用浏览器服务商解密私钥,其它用户信息则通过读写程序从用户信息数据库中读取。签名验证是验证用户证书的服务商签名,加密信息解密时要使用相应的私钥。用户口令认证时需对用户密码进行单向加密,提出挑战时需生成一个随机数。认证客户和服务器之间采用UDP传输协议传输数据包。认证过程中要登记用户信息时通过读写程序写入用户信息数据库。
8.5应用服务器软件设计
如图34所示。应用服务器上存有特别客户端服务商签名私钥和解密私钥,Wi-Fi用户机服务商签名私钥和解密私钥以及其它用户信息则通过用户信息读写程序从用户信息数据库中读取。安全处理的中间层包括对称加密和公钥证书读取程序,上层包括签名、解密、签名验证和公钥非对称加密。应用信息读写程序负责应用数据库的读写。在TCP和UDP协议基础上实现本系统特别设计的应用层协议RRWMTP、P2PWMTP、DBWMTP和WGWMTP的服务器端,而系统应用服务程序则建立在上述应用层协议之上。应用服务程序包括公共信息发布、检索和浏览,分类信息发布、检索和浏览,即时通信、群组通信和消息留言,广告信息区域广播,考勤管理、买卖商城、办公及业务管理、小区物业管理等等。
8.6 Web服务器软件设计
用户通过浏览器和Web服务器使用系统应用服务。如图35所示。Web服务器上存有通用浏览器服务商签名私钥和解密私钥,Wi-Fi用户机服务商签名私钥和解密私钥以及其它用户信息则通过用户信息读写程序从用户信息数据库中读取。安全处理的中间层包括对称加密和公钥证书读取程序,上层包括签名、解密、签名验证和公钥非对称加密。应用信息读写程序负责应用数据库的读写。应用层协议可选用HTTP,或者S-HTTP,或者HTTP/TLS,在TCP基础上实现其服务器端,而Web应用服务程序则建立在选用的应用层协议基础之上。浏览器用户通过Web服务器进行身份认证,需实现认证协议客户端,认证成功将建立用户访问控制表。Web应用服务程序包括公共信息发布、检索和浏览,分类信息发布、检索和浏览,消息留言,考勤管理、买卖商城、办公及业务管理、小区物业管理等等。Web认证处理程序负责浏览器用户的认证交互。
8.7通用浏览器软件设计
用户通过有线上网的PC机(手提电脑)和浏览器使用系统应用服务。如图36所示。当连接有Wi-Fi用户机时,将通过USB主机客户程序使用Wi-Fi用户机上的安全信息和安全处理功能。当没有连接Wi-Fi用户机时,可以下载公钥证书验证签名,可以生成随机密码串进行对称加密,可以下载服务商加密公钥加密对称密码串,但没有用户私钥进行签名和解密,Web服务器响应请求时使用客户端生成的密码串进行对称加密。应用层协议可选用HTTP,或者S-HTTP,或者HTTP/TLS,在TCP协议基础上实现其客户端,而应用客户程序和认证处理程序则建立在选用的应用层协议基础之上,一般通过动态页面来实现。
8.8 Wi-Fi用户机USB通信软件设计
如图37所示,当Wi-Fi用户机通过USB接口与PC机(手提电脑)连接时,通过USB主机客户程序,PC机既能使用Wi-Fi用户机上的安全信息和安全处理功能,也能读取公钥证书、公共信息、分类信息、应用信息等各种信息资料,还能对Wi-Fi用户机进行设置。
8.9邮件服务器软件设计
如图38所示。邮件服务器上存有特别客户端服务商签名私钥和解密私钥,Wi-Fi用户机服务商签名私钥和解密私钥以及其它用户信息则通过用户信息读写程序从用户信息数据库中读取。安全处理的中间层包括对称加密和公钥证书读取程序,上层包括签名、解密、签名验证和公钥非对称加密。邮件信息可以使用文件系统存放,也可以使用邮件数据库存放,邮件信息读写程序负责读写。在TCP协议基础上实现SMTP发送接收服务、POP3服务和IMAP4服务,邮件结构选用MIME或S/MIME标准,并以此为基础建立邮件应用服务程序。
8.10 PKI应用服务器软件设计
如图39所示。PKI应用服务器主要提供密钥管理和公钥证书管理服务,用户生成签名和加密密钥对时,将公钥传给服务器,生成公钥证书后再提交给PKI证书库保存,以后用户还可以更换或作废自己的公钥证书,而其他用户要使用公钥证书时,将通过服务器从PKI证书库中读取;用户也可以将解密私钥传给服务器,存入密钥备份数据库中进行备份,以后密钥丢失时可通过服务器从密钥备份数据库中恢复。PKI应用服务器与客户端的通信传输采用本系统特别设计的RRWMTP协议,而公钥证书则采用X.509标准格式。通信传输内容主要包括客户端提交用户公钥和解密私钥,或提出公钥更换作废和私钥备份恢复请求,或从服务器下载公钥证书。为了保证通信传输安全,PKI应用服务器上存有特别客户端服务商签名私钥和解密私钥,通用浏览器服务商签名私钥和解密私钥,Wi-Fi用户机服务商签名私钥和解密私钥以及其它用户信息则通过用户信息读写程序从用户信息数据库中读取,在此基础上再对传输内容进行签名、解密、签名验证、对称加密和密码串公钥非对称加密。本系统外部的系统或用户也可以请求下载公钥证书,但需通过本系统的Web服务器,由Web服务器采用RRWMTP协议向PKI应用服务器提交请求和下载。
8.11数据库设计
如图40所示,核心基础是系统信息、产品信息和用户信息数据库,其它数据库都与三者关联。系统信息包括区域位置、信息分类、应用服务等系统级编码定义;产品信息登记与产品批次相对应的服务商签名和加密密钥、分配UID之后的产品用户证书;用户信息登记用户个人资料、登录密码、应用服务权限,以及连网信息、状态,上线下线信息,群组用户资料,企业用户资料。PKI服务部分包括PKI证书数据库和密钥备份数据库。即时信息数据库存放群组通信信息和用户离线后所收到的即时通信信息,用户在线时可根据用户需要在点对点通信的同时也向服务器发送一份。邮件信息可以通过文件系统存放,也可以纳入数据库中。广告信息指通过区域广播主动发送,用户被动接收的信息。应用信息数据库则需根据应用的具体要求进行设计。
九、应用服务软件设计(图41)
应用服务软件是以应用层协议为基础进行开发,包括HTTP、SMTP、POP3、IMAP4、RRWMTP、P2PWMTP、WGWMTP、DBWMTP等协议。传输内容可采用HTML、XML或其它合适格式。
9.1即时通信
本系统提供的基本应用服务,访问控制类型可选择位或模块权限(5 bit-or-basedmodule authority),应用层协议采用P2PWMTP。
9.2群组通信
本系统提供的基本应用服务,访问控制类型可选择位或模块权限,登记用户权限时需连上群组识别编号GID,应用层协议采用WGWMTP。
9.3消息留言
一般结合进其它应用中,采用RRWMTP或HTTP协议。
9.4电子邮件
以SMTP、POP3、IMAP4协议为基础,访问控制类型选择位或模块权限。
9.5公共信息发布、检索和浏览
用户可以自由地检索和浏览公共信息,但发布公共信息的权限要受严格控制,一般从公共信息类别和区域位置两个方面进行限制,访问控制类型可选择位或角色(2bit-or-based role)。Wi-Fi用户机、特别客户端以RRWMTP协议为基础,通用浏览器则用HTTP协议。
9.6分类信息发布、检索和浏览
用户可以检索和浏览分类信息,并可根据自己的需要选择区域位置发布分类信息。考虑到需要管理人员进行监控,访问控制类型可选择整数分级权限(3integer-based grade authority)。Wi-Fi用户机、特别客户端以RRWMTP协议为基础,通用浏览器和Web服务器则用HTTP协议。
9.7广告信息区域广播
用户进入指定区域时将被动接收AP广播,但广告信息的发布由服务商授权控制,一般是对区域位置进行限制,访问控制类型选择位或角色,并在DBWMTP协议基础上设计开发。
9.8企业单位考勤管理
为企业单位提供的应用服务,企业需以实体群组进行登记,并为企业分配一个群组识别编号GID,企业所属员工则与企业GID关联。企业办公所在区域需安装Wi-FiAP机,每个员工都配置一台Wi-Fi用户机,设置用户访问控制权限时,应指定Wi-FiAP机具体位置为企业办公区域的AP机位置,这样员工进入办公区域时就可通过Wi-Fi用户机进行上下班考勤登记(与刷卡类似)。需要区分普通员工、人事管理等角色,访问控制类型选择位或角色。Wi-Fi用户机、特别客户端以RRWMTP协议为基础,通用浏览器和Web服务器则用HTTP协议。
9.9买卖商城
用户可以检索和浏览商家、商店及商品资料。用户登记注册为商家后就可开设网上商店,发布自己的商品资料。用户作为卖方时可对卖方定单进行管理,作为买方时可对买方定单进行管理。需要区分普通用户、商家、买方、管理员等角色,访问控制类型选择位或角色。Wi-Fi用户机、特别客户端以RRWMTP协议为基础,通用浏览器和Web服务器则用HTTP协议。
9.10企业单位办公及业务管理
为企业单位提供的应用服务,企业需以实体群组进行登记,并为企业分配一个群组识别编号GID,企业所属员工则与企业GID关联。包括网上办公、进销存、CRM、ERP等,访问控制类型根据需要选择整数角色(1 integer-based role)或位或角色。Wi-Fi用户机、特别客户端以RRWMTP协议为基础,通用浏览器和Web服务器则用HTTP协议。
9.11小区物业管理
小区由业主委员会或物业管理公司出面登记为实体群组,分配一个群组识别编号GID,小区住户与小区GID关联。小区内需安装Wi-FiAP机,每家住户都配置有Wi-Fi用户机,设置用户访问控制权限时,应指定Wi-FiAP机具体位置为小区的AP机位置,这样住户进入小区时就可通过Wi-Fi用户机查看和办理物业事务。需要区分普通住户、物业管理等角色,访问控制类型选择位或角色。Wi-Fi用户机、特别客户端以RRWMTP协议为基础,通用浏览器和Web服务器则用HTTP协议。