一种按地域分层次无线信息发布搜索交流应用系统
阅读：612发布：2022-03-09
专利汇可以提供一种按地域分层次无线信息发布搜索交流应用系统专利检索，专利查询，专利分析的服务。并且本 发明 公开了一种按地域分层次无线信息发布搜索交流应用系统，它属于无线通信、网络和信息技术领域。本系统由用户接入、广域网络、 服务器 和 数据库 四个部分组成，用户接入主要由Wi－Fi用户机或连有Wi－Fi用户机的移动电脑通过Wi－Fi AP机接入互联网。Wi－Fi用户机内有用户证书，签名和解密私钥等安全信息和 算法 。信息区分为国家、城市、地段和热点四个层次，而Wi－Fi AP机则需根据所在区域 位置 设置位置信息，因此通过AP机能限制接收对应层次的信息。本系统定义了身份认证、 访问 控制、无线消息传输等协议。利用本发明可以在全国甚至全世界范围建立统一的 覆盖 城镇商业中心商务中心社区中心和交通中心的商用Wi－Fi网络，为人们提供灵活方便价格低廉安全可靠的数据通信平台。，下面是一种按地域分层次无线信息发布搜索交流应用系统专利的具体信息内容。
1、一种按地域分层次无线信息发布搜索交流应用系统，其特征在于它包括用户接入、广 域网络、服务器、数据库、身份认证/认证协议/访问控制、无线消息传输、消息传输安全/PKI 服务和信息层次/信息分类：
用户接入包括：Wi-Fi用户机，连有Wi-Fi用户机的移动电脑，它们通过Wi-Fi AP机接 入互联网，连或不连Wi-Fi用户机的PC机，通过有线网络接入互联网，手机，通过移动通信 网接入互联网；
广域网络直接采用国际互联网，包括城域网和主干网，城域网可用有线(光纤)，也可用 无线(WiMAX)，主干网可用光纤，也可用卫星；
服务器包括认证服务器、PKI应用服务器、邮件服务器、应用服务器和Web服务器：认 证服务器用于用户身份认证服务，Wi-Fi AP机、安装有系统认证客户端软件的PC机(手提 电脑)和Web服务器都可以作为认证客户，PKI应用服务器用于密钥及证书管理服务，不仅 系统内部的邮件服务器、应用服务器和Web服务器需请求它的安全服务，外部系统或用户也 可通过Web服务器下载公钥证书，邮件服务器用于邮件发送、接收、存储、管理、安全等服 务，应用服务器为Wi-Fi用户机用户和特别客户端用户提供公共信息发布、检索和浏览，分 类信息发布、检索和浏览，即时通信、群组通信和消息留言，广告信息区域广播，考勤管理、 买卖商城、办公及业务管理、小区物业管理等应用服务，Web服务器为通用浏览器用户提供 身份认证，公钥证书下载，公共信息发布、检索和浏览，分类信息发布、检索和浏览，消息 留言，考勤管理、买卖商城、办公及业务管理、小区物业管理等服务；
数据库包括：系统信息、产品信息、用户信息数据库，它们是基础，另有邮件信息、公 共信息、分类信息、即时信息、留言信息、广告信息、应用信息、PKI证书、密钥备份数据 库，它们与前三个数据库相关联；
身份认证/认证协议/访问控制包括5种身份认证过程和5种访问控制类型，并参照 RADIUS协议的基本框架模式设计了一套标准的认证协议，在该认证协议基础上可实现上述 认证过程和访问控制；
无线消息传输包括请求-响应、点到点(P2P)、按地域广播和群组4种消息传输模式，并 在应用层设计了与4种消息传输模式分别对应的标准无线消息传输协议；
消息传输安全/PKI服务以公钥证书体系为基础，对密钥类型及用途、密钥生成使用及管 理方法进行了设计，并且融合到消息传输协议及认证协议当中；
信息层次/信息分类将信息划分成国家(地区)、城市、地段和热点(信息点)四个层次， 区分为公共信息、分类信息、即时信息、留言信息、邮件信息、广告信息和应用信息等类型， 再与Wi-Fi AP机位置信息、认证协议和消息传输协议相结合，能为各种信息提供自然的筛选、 分类和聚合的能力，为人们查找和交流信息提供极大的方便。
2、根据权利要求1所述按地域分层次无线信息发布搜索交流应用系统，其特征在于，所 述Wi-Fi用户机包括处理器、存储模块、无线通信模块、USB总线接口、用户接口模块和用 户信息模块，其中处理器用于整个装置的中央处理控制，一般用32位嵌入式处理器；存储模 块用于存储信息，它包括程序存储、数据存储、资料存储；无线通信模块用于无线通信信号 的发送、接收、处理和控制，它包括Wi-Fi基带处理和MAC控制、2.4GHz无线收发、天线； USB总线接口用于连接PC机，作为USB设备与PC机通信；用户接口模块用于用户操作交 互，它包括按键、LCD控制、LCD显示；用户信息模块用于存放用户安全信息，它包括用户 证书、签名私钥、解密私钥、私钥口令，下载的签名公钥证书、加密公钥证书；
所述Wi-Fi AP机包括处理器、存储模块、无线通信模块、以太网通信模块、广域网通信 模块、ADSL通信模块和LED。
3、根据权利要求1或2所述按地域分层次无线信息发布搜索交流应用系统，其特征在于， 所述系统的Wi-Fi用户机内有一份Wi-Fi用户证书，作为用户登录和使用系统的凭证，内容 包括MAC地址、SSID、产品批次、生产商、软件系统版本号、用户识别编号UID、服务商 数字签名、服务商加密公钥，用户识别编号UID由服务商分配，在系统内唯一，对每一批 Wi-Fi用户机，服务商要生成单独的签名密钥对和加密密钥对，并在产品信息数据库中进行备 案记录。
4、根据权利要求1所述的无线信息发布搜索交流应用系统，其特征在于，所述系统的认 证协议为：参照RADIUS协议的基本框架模式，定义了认证协议包格式和类型，包括的各种 属性，认证协议包定义的属性包括：User-Name(用户名，本系统为用户识别编号UID)， User-Password(用户证书认证时是产品批次，用户口令认证时是经服务商加密公钥加密的用 户密码，用户登出时是会话期间一直保持的挑战随机数，用户挑战应答时是经服务商加密公 钥加密的挑战数字)，Auth-Client-Type(认证客户类型，包括Wi-Fi AP机、安装有特别客户 端软件的PC机、Web服务器)，Auth-Client-IP-Address(认证客户IP地址)，User-IP-Address (用户IP地址)，Service-Type(服务类型)，Wi-Fi-AP-Position(Wi-Fi AP机所在位置)， MAC-Address(Wi-Fi用户机MAC地址)，SSID(Wi-Fi网络名称，本系统作为服务商名称)， Producer(Wi-Fi用户机生产商)，Soft-Version(Wi-Fi用户机软件版本)， Service-Provider-Signature(服务商对Wi-Fi用户机用户证书的签名)，Reply-Message，State， User-Access-Control(用户访问控制，每一种应用服务需对应一项访问控制)，Session-Timeout， Idle-Timeout。
5、根据权利要求1所述的无线信息发布搜索交流应用系统，其特征在于，所述系统的身 份认证过程包括：基于Wi-Fi用户机和Wi-Fi AP机、基于Wi-Fi用户机和特别客户端、基于 Wi-Fi用户机和通用浏览器、基于用户口令和特别客户端、基于用户口令和通用浏览器；
所述访问控制系统应用服务统一编号，访问控制类型包括integer-based role(整数角色)、 bit-or-based role(位或角色)、integer-based grade authority(整数分级权限)、integer-based module authority(整数模块权限)、bit-or-based module authority(位或模块权限)，企业以实体群组进 行登记并分配一个群组识别编号GID，企业员工使用企业应用服务时要与企业GID关联，可 对应用服务访问区域进行限制。
6、根据权利要求1所述的无线信息发布搜索交流应用系统，其特征在于，所述系统的请 求-响应无线消息传输协议(RRWMTP)为：类似于HTTP协议，统一资源标识符(URI)格 式rrwmtp_URL＝″rrwmtp:″″//″host[″:″port][abs_path[″？″query]]；RRWMTP消息基本框 架与HTTP消息相同，general-header部分保留Cache-Control、Date、Pragma、Transfer-Encoding、 Via、Warning等字段，增加字段State(挑战随机数)、Message-From(发送本消息的最初用 户UID)、Message-To(接收本消息的最终目标用户UID)；Request基本框架与HTTP相同， Request方法保留GET、POST、PUT、DELETE，request-header部分保留Accept、Accept-Charset、 Accept-Encoding、Accept-Language、Host、User-Agent等字段，增加字段AP-Position(传送 用户请求的Wi-Fi AP机的位置信息)；Response基本框架与HTTP相同，response-header部分 保留Age、Location、Retry-After、Server、Vary等字段，增加状态码430 State Error、431 Message-From Error、432 Message-To Error、433 AP-Position Error、434 Signature Error；Entity 基本框架与HTTP相同，entity-header部分保留Allow、Content-Encoding、Content-Language、 Content-Length、Content-Range、Content-Type、Expires、Last-Modified等字段，增加字段 User-Signature(发送本消息用户的签名)、Content-Encrypt-Key(消息体加密密码)、 Signature-Key-Type(发送本消息用户的签名密钥类型)、Encrypt-Key-Type(本消息接收者的 加密密钥类型)；Wi-Fi AP机作为协议代理(proxy)，为用户提供应用访问控制，为信息发布 搜索交流应用提供区域位置信息，为消息响应提供缓存(cache)；
所述系统的点到点无线消息传输协议(P2PWMTP)为：参照HTTP协议和SIP协议，统 一资源标识符(URI)p2pwmtp:user@host:port；uri-parameters？headers(user为用户识别编号 UID)；用Request INVITE方法向应用服务器提出请求，服务器响应Response回送对方在线 情况和IP地址等信息，不在线通过Request MESSAGE方法将消息先发给服务器，用户结束 消息发送时提交Request BYE方法；与服务器之间仍采用request-response模式，消息基本结 构与RRWMTP相同；双方同时在线将建立直接通信连接，通过命令/应答方式传送消息，传 送消息命令由命令行(Command-Line)、general-header、entity-header和entity-body几部分组 成，命令行格式Command-Line＝Command SP P2PWMTP-URI SP P2PWMTP-Version CRLF， Command包括MES SAGE和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、434 Signature Error、480 Temporarily Unavailable、489 Log Out；entity-header部 分增加字段Public-Key-User(加密公钥用户UID)；Wi-Fi AP机作为协议代理(proxy)，为用 户提供应用访问控制，如果两个用户通过服务器确认在同一个AP机通信区域内，此时应能 直接建立网内通信连接；
所述系统的区域广播无线消息传输协议(DBWMTP)为：协议框架和消息结构与 P2PWMTP协议基本相同，统一资源标识符(URI)格式 dbwmtp:district@host:port；uri-parameters？headers(district为区域信息，格式为国家.城市.地段. 热点)；用Request BROADCAST方法向应用服务器提出广播请求，服务器检查消息和用户权 限，有问题则给出Client Error响应(response)，没有问题服务器将生成一个广播编号(系统 内唯一)，并给出成功response，其response-header部分增加字段Broadcast-ID(广播编号)； 与服务器之间仍采用request-response模式，消息基本结构与RRWMTP相同，Message-To字 段内容设为广播区域信息；服务器进行区域广播(根据区域信息逐一找出区域内的Wi-Fi AP 机，建立UDP通信连接，并将消息发送给AP机，消息response-header部分加上Broadcast-ID 字段)；Wi-Fi AP机在其通信区域内进行AP广播，可通过消息中字段Date、Expires和 Cache-Control控制AP广播行为，包括timing-broadcast(定时广播)、scaling-broadcast(定数 广播)、login-broadcast(登录广播)三种模式；服务器向特定区域广播消息时，先将消息发 给区域内的Wi-Fi AP机，再由AP机通过网内广播发给用户，起网关(gateway)作用。用户 通过Wi-Fi AP机向服务器请求广播时，则为用户提供应用访问控制。
所述系统的群组无线消息传输协议(WGWMTP)为：协议框架和消息结构与P2PWMTP 协议基本相同，统一资源标识符(URI)格式wgwmtp:group@host:port；uri-parameters？headers (群组通过识别编号GID唯一标记，group为群组识别编号GID)；群组管理员用Request INVITE方法向应用服务器提出启动群组通信请求，服务器核查权限，通不过则给出Client Error响应(response)，能通过则统计群组总用户数和在线用户数，并给出成功response，其 消息体中包括群组统计结果和当前在线用户清单等信息，服务器对群组通信服务进行初始化， 管理员要结束群组通信时则提交Request BYE方法；发送消息通过Request MESSAGE方法先 将消息发到服务器，头部Message-To字段内容为GID；与服务器之间仍采用request-response 模式，消息基本结构与P2PWMTP相同；服务器逐一通过命令/应答方式将消息转发给群组内 其它在线用户，转发消息由命令行(Command-Line)、general-header、entity-header和entity-body 几部分组成，命令行格式Command-Line＝Command SP WGWMTP-URI SP WGWMTP-Version CRLF，Command包括MESSAGE，general-header、entity-header、entity-body与RRWMTP 基本一致，消息接收者应答时只有一状态行(Status-Line)，格式Status-Line＝ WGWMTP-Version SP Status-Code SP Reason-Phrase CRLF，Status-Code内容与P2PWMTP的 Status-Code相同；群组消息传输Wi-Fi AP机起代理(proxy)作用，主要是为用户提供应用 访问控制。
7、根据权利要求1所述的无线信息发布搜索交流应用系统，其特征在于，所述系统的信 息层次包括：国家(地区)(表示一个国家或行政管辖相对独立的地区)，城市(表示现实的 行政或经济意义上的城市)，地段(表示城市内人口、公共资源、服务设施和人员流动相对集 中的区域，如城镇商业中心、商务中心、社区中心和交通中心)，热点(信息点)(在地段范 围内统一编码，可根据实际情况和需要随时安排、设置和定义)，Wi-Fi AP机需根据所在区域 位置设置具体的位置信息，因此通过AP机能限制接收对应层次的信息，当信息层次指定为 热点时只有在该热点才能检索和浏览，当信息层次指定为地段时在该地段的所有热点都能检 索和浏览，当信息层次指定为城市时在该城市内的所有热点都能检索和浏览，当信息层次指 定为国家(地区)时在该国家(地区)内的所有热点都能检索和浏览；
所述信息区分为大类和细分类，大类包括：公共信息，分类信息，即时信息，留言信息， 邮件信息，广告信息，应用信息；公共信息一般由服务商主动提供，由服务商负责收集、整 理和维护，并与具体的区域位置(国家.城市.地段)相对应，细分为：新闻、天气预报、交通 状况、旅游景点、地方特色、政府公告、民生公告、公共交通、公共服务、公共设施、街道 马路、特色店号；分类信息一般由用户自己发布，发布的区域位置也由用户根据自己的需要 选择，并由用户自己负责信息刷新、修改和删除，细分为：促销活动、餐饮美食、房屋地产、 商店门面、酒吧夜总会、旧货交易、招聘、求职、征婚、团购、产品招商、寻人启事、寻物 启事、失物招领、转让车票、电影院线、搬家搬屋、家政清洁、装饰装修、家教、水电安装、 泥瓦杂工、通厕通管、废品收购、地产经纪、医疗门诊、家电维修、美容美发、婚纱摄影、 婚礼婚庆、旅游、敬老院、花卉园艺、快递、物流货运、心理咨询、保健按摩、桑拿沐足、 名片复印、印刷排版、汽车维修、保险证券、培训招生、驾驶驾照、留学咨询、票务、建筑 设计、广告策划、工商注册、电脑网络、软件开发、管理咨询、租车、典当拍卖、物业管理、 监理、律师、会计、审计、资产评估、商标专利、礼仪公关、翻译；
当用户持Wi-Fi用户机进入某个热点(Wi-Fi AP机)通信范围内时，能检索和浏览该热 点及热点所属的地段、城市、国家(地区)内的公共信息和分类信息，能将自己的分类信息 发布到该热点及热点所属的地段、城市、国家(地区)，能发送和接收自己的即时信息、留言 信息和邮件信息，能操作自己获得了相应操作权限的应用信息。
8、根据权利要求1所述的无线信息发布搜索交流应用系统，其特征在于，所述系统的消 息传输安全方法包括：有Wi-Fi用户机时：服务商根据Wi-Fi用户机产品批次生成一对签名 密钥和一对加密密钥，加密公钥包含在用户证书当中，并用服务商签名私钥对证书进行签名； 用户可通过Wi-Fi用户机申请自己的签名密钥对和加密密钥对，作为Wi-Fi用户机专用密钥， 私钥保存在用户机上，公钥则以X.509证书形式保存在PKI证书库中，用户还可设置一个口 令保护签名私钥，需要签名时，提示用户输入口令，口令正确才能解锁和签名；用户可通过 Wi-Fi用户机设置登录密码，在没有Wi-Fi用户机时就能通过特别客户端软件或者通用浏览器 使用UID和用户密码登录系统；
没有Wi-Fi用户机时：针对特别客户端，服务商专门生成一对签名密钥和一对加密密钥， 公钥以X.509证书形式保存在PKI证书库中并对外发布；用户可通过客户端软件申请自己的 签名密钥对和加密密钥对，作为特别客户端软件专用密钥，私钥保存在客户端，公钥则以X.509 证书形式保存在PKI证书库中，用户还可设置一个口令保护签名私钥，需要签名时，提示用 户输入口令，口令正确才能解锁和签名；
没有Wi-Fi用户机时：针对通用浏览器，服务商专门生成一对签名密钥和一对加密密钥， 公钥以X.509证书形式保存在PKI证书库中并对外发布；用户没有私钥进行签名和解密；
消息签名：消息发送方可使用Wi-Fi用户机或特别客户端的签名私钥对消息进行签名， 消息接收方通过下载对方签名脱密公钥验证对方签名；
消息加密：需要加密的消息如果是通过Wi-Fi用户机或特别客户端或浏览器发出，首先 在发出地点生成随机密码串，并用它对消息进行对称加密，然后再使用服务商加密公钥或接 收方加密公钥对随机密码串进行非对称加密。服务器转发消息时，如果对称密码串是用服务 商加密公钥加密，先解密，再使用接收方加密公钥加密。服务器直接向用户发送消息时，先 生成随机密码串进行对称加密，再使用接收方加密公钥加密。Web服务器响应浏览器加密请 求时，直接使用请求客户生成和传递过来的对称密码串进行对称加密。接收到加密消息后， 使用接收端相应私钥解密；
消息压缩、签名和加密顺序：签名->压缩->生成密码串进行对称加密->对密码串进 行非对称加密。
技术领域
本发明涉及无线通信、网络和信息技术领域，特别是涉及一种基于Wi-Fi、互联 网和PKI的无线网络信息发布搜索交流应用的系统技术。
背景技术
IEEE 802.11无线局域网(Wi-Fi)协议标准包括802.11、802.11a、802.11b、802.11g、 802.11i、802.11h、802.11e、802.11n等，而且新的更高速更安全的协议标准草案也在 不断提出，如中国就曾提出了自己的强制性国家标准WAPI(GB 15629.11-2003)。作 为计算机数据通信有线网络的一种替代方案，Wi-Fi在企业组网方面应用已相当普遍。 但如果要建一个全国性的Wi-Fi网络，目前却缺乏足够的应用作为业务支撑，实际推 出的如Wi-Fi手机，想与移动话音业务运营商竞争，不仅会受到政府政策的限制，而 且在网络覆盖范围、高速移动、语音通信服务质量等方面永远无法跟2.5G、3G、4G 等移动通信网络相比。而发达国家的一些城市由政府出资在公共场所建立Wi-Fi热点 作为城市的基础设施，其应用基本上仅限于手提电脑、PDA、智能手机等用户无线上 网，商业价值不大。
以话音业务为主的移动通信业务，从2G、2.5G、3G，不断向宽带移动数据通信 发展，但技术复杂，成本高昂。2.5G以下数据通信能力有限，3G、4G虽有了足够 的数据通信能力，但其数据通信与语音通信一样建立在高覆盖范围、高速移动的基础 之上，要负担同样高的成本和费用。如运营商为了收益光计费方案就要绞尽脑汁，加 之条块分割既有长途又有漫游，包括在通信网络当中的计费系统就需花费昂贵代价。
实际上，大多数的数据通信并不需要语音通信那样的高覆盖范围和高速移动，仅 仅需要一定的灵活性和方便性即可。因此，城镇等人口稠密区域的数据通信使用定点 Wi-Fi网络已足够灵活方便，而且成本低廉。数据通信以Wi-Fi网络为主，移动通信 网络作为补充；语音通信以移动网络为主，Wi-Fi网络可以补充。
本发明是在Wi-Fi网络和互联网基础上基于TCP/IP设计了一整套数据通信和信 息交流的应用框架及系统方案，主要是在应用层进行设计(包括网络安全方面)，网 络层及以下可以兼容各种相关协议标准。以此应用框架为基础，可以在全国甚至全世 界范围建立一个统一的覆盖城镇商业中心、商务中心和社区中心的商用Wi-Fi网络， 扩充灵活，使用方便。
每个Wi-Fi热点通信覆盖范围有限(一般在100m之内)，因此Wi-Fi网络有自然 的地域特性和定位功能，本发明充分应用Wi-Fi网络的这些特点，对信息发布、信息 搜索、信息交流和信息应用按地域进行层次划分，从而为各种信息提供自然的筛选、 分类和聚合的能力，为人们查找和交流信息提供极大的方便。
本发明设计的数据通信和信息交流应用框架包括以下内容：
1)为各种应用提供统一的足够安全的身份认证和访问控制
2)通过Wi-Fi热点代理上互联网
3)按地域分层次公共信息发布、检索和浏览，如新闻、天气预报、交通、 旅游、公告、公共服务等
4)按地域分层次个人、企业、单位分类信息发布、检索和浏览
5)足够安全的即时通信、群组通信和消息留言
6)足够安全的邮件接收和发送
7)足够灵活方便高效的广告信息区域广播
8)足够安全的企业应用，如考勤管理、买卖商城、办公及业务管理、小区 物业管理等
9)通用PKI服务，包括安全策略、密钥及证书管理、应用接口等
IEEE 802.11X协议标准虽有一些安全方面的设计，但不足以支持一个超大规模应 用网络的安全要求。本发明综合身份认证、访问控制、通用PKI服务的需要统一在应 用层进行安全方面的设计。计费一般直接针对应用或服务项目，通常采用按条或包期 (月，年)方式。
以话音业务为主的移动通信业务，从2G、2.5G、3G，不断向宽带移动数据通信 发展，但技术复杂，成本高昂。2.5G以下数据通信能力有限，3G、4G虽有了足够 的数据通信能力，但其数据通信与语音通信一样建立在高覆盖范围、高速移动的基础 之上，要负担同样高的成本和费用。如运营商为了收益光计费方案就要绞尽脑汁，加 之条块分割既有长途又有漫游，包括在通信网络当中的计费系统就需花费昂贵代价。
实际上，大多数的数据通信并不需要语音通信那样的高覆盖范围和高速移动，仅 仅需要一定的灵活性和方便性即可。因此，城镇等人口稠密区域的数据通信使用定点 Wi-Fi网络已足够灵活方便，而且成本低廉。数据通信以Wi-Fi网络为主，移动通信 网络作为补充；语音通信以移动网络为主，Wi-Fi网络可以补充。
本发明是在Wi-Fi网络和互联网基础上基于TCP/IP设计了一整套数据通信和信 息交流的应用框架及系统方案，主要是在应用层进行设计(包括网络安全方面)，网 络层及以下可以兼容各种相关协议标准。以此应用框架为基础，可以在全国甚至全世 界范围建立一个统一的覆盖城镇商业中心、商务中心和社区中心的商用Wi-Fi网络， 扩充灵活，使用方便。
每个Wi-Fi热点通信覆盖范围有限(一般在100m之内)，因此Wi-Fi网络有自然 的地域特性和定位功能，本发明充分应用Wi-Fi网络的这些特点，对信息发布、信息 搜索、信息交流和信息应用按地域进行层次划分，从而为各种信息提供自然的筛选、 分类和聚合的能力，为人们查找和交流信息提供极大的方便。
本发明设计的数据通信和信息交流应用框架包括以下内容：
1)为各种应用提供统一的足够安全的身份认证和访问控制
2)通过Wi-Fi热点代理上互联网
3)按地域分层次公共信息发布、检索和浏览，如新闻、天气预报、交通、 旅游、公告、公共服务等
4)按地域分层次个人、企业、单位分类信息发布、检索和浏览
5)足够安全的即时通信、群组通信和消息留言
6)足够安全的邮件接收和发送
7)足够灵活方便高效的广告信息区域广播
8)足够安全的企业应用，如考勤管理、买卖商城、办公及业务管理、小区 物业管理等
9)通用PKI服务，包括安全策略、密钥及证书管理、应用接口等
IEEE 802.11X协议标准虽有一些安全方面的设计，但不足以支持一个超大规模应 用网络的安全要求。本发明综合身份认证、访问控制、通用PKI服务的需要统一在应 用层进行安全方面的设计。计费一般直接针对应用或服务项目，通常采用按条或包期 (月，年)方式。
发明内容
本发明提出了一种按地域分层次无线信息发布搜索交流应用系统，它是在Wi-Fi 网络、互联网和PKI基础上基于TCP/IP设计的一整套安全的数据通信和信息交流应 用框架及系统方案。
为了实现发明目的，采用的技术方案如下：
1、系统整体结构
系统包括用户接入、广域网络、服务器和数据库四个部分。
1.1用户接入
包括：Wi-Fi用户机，连有Wi-Fi用户机的移动电脑，它们通过Wi-Fi AP机接入 互联网；连或不连Wi-Fi用户机的PC机(手提电脑)，通过有线网络(拨号，xDSL 等)接入互联网；手机，通过移动通信网接入互联网。其中Wi-Fi用户机和Wi-FiAP 机要专门针对本系统设计。
Wi-Fi用户机包括处理器、存储模块、无线通信模块、USB总线接口、用户接口 模块和用户信息模块：处理器用于整个装置的中央处理控制，一般用32位嵌入式处 理器；存储模块用于存储信息，它包括程序存储、数据存储、资料存储；无线通信模 块用于无线通信信号的发送、接收、处理和控制，它包括Wi-Fi基带处理和MAC控 制、2.4GHz无线收发、天线；USB总线接口用于连接PC机(手提电脑)，作为USB 设备与PC机通信；用户接口模块用于用户操作交互，它包括按键、LCD控制、LCD 显示；用户信息模块用于存放用户安全信息，它包括用户证书、签名私钥、解密私钥、 私钥口令，下载的签名公钥证书、加密公钥证书。
Wi-Fi AP机包括处理器、存储模块、无线通信模块、以太网通信模块、广域网通 信模块、ADSL通信模块和LED：处理器用于整个装置的中央处理控制，一般用32 位嵌入式处理器；存储模块用于存储信息，它包括程序存储、数据存储、资料存储； 无线通信模块用于无线通信信号的发送、接收、处理和控制，它包括Wi-Fi基带处理 和MAC控制、2.4GHz无线收发、天线；以太网通信模块用于有线局域网通信，广 域网通信模块用于互联网通信，包括Ethernet MAC/MII、10/100 LAN PHY、10/100 WAN PHY；ADSL通信模块用于宽带接入，它包括ADSL收发器、模拟前端AFE、 LINE DRIVER；LED用于状态显示。
1.2广域网络
直接采用国际互联网(internet)。包括城域网和主干网，城域网可用有线(光纤)， 也可用无线(WiMAX)；主干网可用光纤，也可用卫星。可以自建广域通信网络，也 可以向电信服务商租用。
1.3服务器
包括认证服务器、PKI应用服务器、邮件服务器、应用服务器和Web服务器： 认证服务器用于用户身份认证服务，Wi-Fi AP机、安装有系统认证客户端软件的PC 机(手提电脑)和Web服务器都可以作为认证客户；PKI应用服务器用于密钥及证 书管理服务，不仅系统内部的邮件服务器、应用服务器和Web服务器需请求它的安 全服务，外部系统或用户也可通过Web服务器下载公钥证书；邮件服务器用于邮件 发送、接收、存储、管理、安全等服务；应用服务器为Wi-Fi用户机用户和特别客户 端用户提供公共信息发布、检索和浏览，分类信息发布、检索和浏览，即时通信、群 组通信和消息留言，广告信息区域广播，考勤管理、买卖商城、办公及业务管理、小 区物业管理等应用服务；Web服务器为通用浏览器用户提供身份认证，公钥证书下载， 公共信息发布、检索和浏览，分类信息发布、检索和浏览，消息留言，考勤管理、买 卖商城、办公及业务管理、小区物业管理等服务。
1.4数据库
包括：系统信息、产品信息、用户信息数据库，它们是基础，另有邮件信息、公 共信息、分类信息、即时信息、留言信息、广告信息、应用信息、PKI证书、密钥备 份数据库，它们与前三个数据库相关联。
2、身份认证、认证协议和访问控制
身份认证：根据用户使用情况设计了基于Wi-Fi用户机和Wi-FiAP机、基于Wi-Fi 用户机和特别客户端、基于Wi-Fi用户机和通用浏览器、基于用户口令和特别客户端、 基于用户口令和通用浏览器五种认证过程。
认证协议：参照RADIUS协议的基本框架模式，定义了认证协议包格式和类型， 包括的各种属性。
访问控制：系统应用服务统一编号，定义了整数角色、位或角色、整数分级权限、 整数模块权限、位或模块权限五种访问控制类型，企业以实体群组进行登记并分配一 个群组识别编号GID，企业员工使用企业应用服务时要与企业GID关联，可对应用服 务访问区域进行限制。
3、无线消息传输
请求-响应无线消息传输协议(RRWMTP)：类似于HTTP协议，定义了统一资源 标识符(URI)、RRWMTP消息基本框架、Request、Response、Entity，并对消息体 的签名和加密方法进行了规定；
点到点无线消息传输协议(P2PWMTP)：参照HTTP协议和SIP协议，定义了统 一资源标识符(URI)、会话邀请和消息转发、点到点消息传输(命令/应答方式)，并 对消息体的签名和加密方法进行了规定；
区域广播无线消息传输协议(DBWMTP)：定义了统一资源标识符(URI)、广播 请求、区域广播、AP广播(三种模式)；
群组无线消息传输协议(WGWMTP)：每个群组分配一个识别编号GID，定义 了统一资源标识符(URI)、启动群组通信、发送消息、转发消息(命令/应答方式)， 并对消息体的签名和加密方法进行了规定；
特别客户端消息传输：实现RRWMTP、P2PWMTP和WGWMTP，但可能连或 不连Wi-Fi用户机，签名和加密选择的密钥需要调整；
通用浏览器消息传输：可采用HTTP、S-HTTP、HTTP/TLS协议，连有Wi-Fi用 户机时可对消息进行签名、加密、签名验证和解密，不连时则无法用私钥签名和解密；
邮件无线传输：对消息体的签名和加密方法进行了规定。
4、消息传输安全和PKI服务
Wi-Fi用户机安全：内有一份用户证书，服务商根据产品批次生成一对签名密钥 和一对加密密钥，加密公钥包含在用户证书当中，并用服务商签名私钥对证书进行签 名。用户可通过Wi-Fi用户机申请自己的签名密钥对和加密密钥对，作为Wi-Fi用户 机专用密钥，私钥保存在用户机上，公钥则以X.509证书形式保存在PKI证书库中。 用户还可设置一个口令保护签名私钥，输入正确口令才能解锁和签名；
用户登录密码：通过Wi-Fi用户机设置，在没有Wi-Fi用户机时也能通过特别客 户端软件或者通用浏览器使用UID和用户密码登录系统；
特别客户端安全：用户可通过客户端软件申请自己的签名密钥对和加密密钥对， 作为特别客户端软件专用密钥(不连Wi-Fi用户机时使用)，私钥保存在客户端，公 钥则以X.509证书形式保存在PKI证书库中。用户还可设置一个口令保护签名私钥， 输入正确口令才能解锁和签名；
PKI服务：遵照X.509规范，定义了几种签名及加密公钥证书类型。
5、信息层次和信息分类
信息层次：包括国家(地区)、城市、地段、热点(信息点)，定义了编码方案， Wi-Fi AP机需根据所在区域位置设置具体的位置信息；
信息分类：区分为大类和细分类，大类包括公共信息、分类信息、即时信息、留 言信息、邮件信息、广告信息和应用信息，定义了编码方案，并对公共信息和分类信 息的细分类进行了详细定义。
本发明有益效果：
1)可以在全国甚至全世界范围建立统一的覆盖城镇商业中心、商务中心、社区 中心和交通中心的商用Wi-Fi网络，扩充灵活，使用方便。
2)能为人们提供灵活方便、价格低廉、安全可靠的数据通信平台。
3)除了提供信息发布、搜索和交流服务，提供考勤管理、买卖商城、办公及业 务管理、小区物业管理等应用服务，还能开发更多应用服务。
4)能有效调配社会资源，给人们的工作、学习和生活带来极大方便。
附图说明
图1为无线信息发布搜索交流应用系统结构框架图；
图2为Wi-Fi用户机结构框架图；
图3为用户信息卡结构和触点功能图；
图4为用户信息模块(单独做成产品)结构图；
图5为Wi-Fi AP机结构框架图；
图6为基于Wi-Fi用户机和Wi-Fi AP机的身份认证过程图；
图7为基于Wi-Fi用户机和特别客户端的身份认证过程图；
图8为基于Wi-Fi用户机和通用浏览器的身份认证过程图；
图9为基于用户口令和特别客户端的身份认证过程图；
图10为基于用户口令和通用浏览器的身份认证过程图；
图11为整数角色访问控制用户、角色等控制关系图；
图12为位或角色访问控制用户、角色等控制关系图；
图13为整数分级权限访问控制用户、角色等控制关系图；
图14为整数模块权限访问控制用户、角色等控制关系图；
图15为位或模块权限访问控制用户、角色等控制关系图；
图16为请求-响应无线消息传输模式图；
图17为点到点(P2P)无线消息传输模式图；
图18为按地域广播无线消息传输模式图；
图19为群组无线消息传输模式图；
图20为连Wi-Fi用户机，特别客户端请求-响应消息传输图；
图21为连Wi-Fi用户机，特别客户端点到点消息传输图；
图22为连Wi-Fi用户机，特别客户端群组消息传输图；
图23为不连Wi-Fi用户机，特别客户端请求-响应消息传输图。
图24为不连Wi-Fi用户机，特别客户端点到点消息传输图；
图25为不连Wi-Fi用户机，特别客户端群组消息传输图；
图26为连Wi-Fi用户机，通用浏览器应用消息传输图；
图27为不连Wi-Fi用户机，通用浏览器应用消息传输图；
图28为系统邮件服务部分结构及通信传输图；
图29为PKI服务系统结构框架图；
图30为Wi-Fi用户机软件功能模块结构及关系图；
图31为特别客户端软件功能模块结构及关系图；
图32为Wi-Fi AP机软件功能模块结构及关系图；
图33为认证服务器软件功能模块结构及关系图；
图34为应用服务器软件功能模块结构及关系图；
图35为Web服务器软件功能模块结构及关系图；
图36为通用浏览器软件功能模块结构及关系图；
图37为Wi-Fi用户机USB通信软件功能模块结构及关系图；
图38为邮件服务器软件功能模块结构及关系图；
图39为PKI应用服务器软件功能模块结构及关系图；
图40为数据库结构及关系图；
图41为应用服务软件简要设计图；
为了实现发明目的，采用的技术方案如下：
1、系统整体结构
系统包括用户接入、广域网络、服务器和数据库四个部分。
1.1用户接入
包括：Wi-Fi用户机，连有Wi-Fi用户机的移动电脑，它们通过Wi-Fi AP机接入 互联网；连或不连Wi-Fi用户机的PC机(手提电脑)，通过有线网络(拨号，xDSL 等)接入互联网；手机，通过移动通信网接入互联网。其中Wi-Fi用户机和Wi-FiAP 机要专门针对本系统设计。
Wi-Fi用户机包括处理器、存储模块、无线通信模块、USB总线接口、用户接口 模块和用户信息模块：处理器用于整个装置的中央处理控制，一般用32位嵌入式处 理器；存储模块用于存储信息，它包括程序存储、数据存储、资料存储；无线通信模 块用于无线通信信号的发送、接收、处理和控制，它包括Wi-Fi基带处理和MAC控 制、2.4GHz无线收发、天线；USB总线接口用于连接PC机(手提电脑)，作为USB 设备与PC机通信；用户接口模块用于用户操作交互，它包括按键、LCD控制、LCD 显示；用户信息模块用于存放用户安全信息，它包括用户证书、签名私钥、解密私钥、 私钥口令，下载的签名公钥证书、加密公钥证书。
Wi-Fi AP机包括处理器、存储模块、无线通信模块、以太网通信模块、广域网通 信模块、ADSL通信模块和LED：处理器用于整个装置的中央处理控制，一般用32 位嵌入式处理器；存储模块用于存储信息，它包括程序存储、数据存储、资料存储； 无线通信模块用于无线通信信号的发送、接收、处理和控制，它包括Wi-Fi基带处理 和MAC控制、2.4GHz无线收发、天线；以太网通信模块用于有线局域网通信，广 域网通信模块用于互联网通信，包括Ethernet MAC/MII、10/100 LAN PHY、10/100 WAN PHY；ADSL通信模块用于宽带接入，它包括ADSL收发器、模拟前端AFE、 LINE DRIVER；LED用于状态显示。
1.2广域网络
直接采用国际互联网(internet)。包括城域网和主干网，城域网可用有线(光纤)， 也可用无线(WiMAX)；主干网可用光纤，也可用卫星。可以自建广域通信网络，也 可以向电信服务商租用。
1.3服务器
包括认证服务器、PKI应用服务器、邮件服务器、应用服务器和Web服务器： 认证服务器用于用户身份认证服务，Wi-Fi AP机、安装有系统认证客户端软件的PC 机(手提电脑)和Web服务器都可以作为认证客户；PKI应用服务器用于密钥及证 书管理服务，不仅系统内部的邮件服务器、应用服务器和Web服务器需请求它的安 全服务，外部系统或用户也可通过Web服务器下载公钥证书；邮件服务器用于邮件 发送、接收、存储、管理、安全等服务；应用服务器为Wi-Fi用户机用户和特别客户 端用户提供公共信息发布、检索和浏览，分类信息发布、检索和浏览，即时通信、群 组通信和消息留言，广告信息区域广播，考勤管理、买卖商城、办公及业务管理、小 区物业管理等应用服务；Web服务器为通用浏览器用户提供身份认证，公钥证书下载， 公共信息发布、检索和浏览，分类信息发布、检索和浏览，消息留言，考勤管理、买 卖商城、办公及业务管理、小区物业管理等服务。
1.4数据库
包括：系统信息、产品信息、用户信息数据库，它们是基础，另有邮件信息、公 共信息、分类信息、即时信息、留言信息、广告信息、应用信息、PKI证书、密钥备 份数据库，它们与前三个数据库相关联。
2、身份认证、认证协议和访问控制
身份认证：根据用户使用情况设计了基于Wi-Fi用户机和Wi-FiAP机、基于Wi-Fi 用户机和特别客户端、基于Wi-Fi用户机和通用浏览器、基于用户口令和特别客户端、 基于用户口令和通用浏览器五种认证过程。
认证协议：参照RADIUS协议的基本框架模式，定义了认证协议包格式和类型， 包括的各种属性。
访问控制：系统应用服务统一编号，定义了整数角色、位或角色、整数分级权限、 整数模块权限、位或模块权限五种访问控制类型，企业以实体群组进行登记并分配一 个群组识别编号GID，企业员工使用企业应用服务时要与企业GID关联，可对应用服 务访问区域进行限制。
3、无线消息传输
请求-响应无线消息传输协议(RRWMTP)：类似于HTTP协议，定义了统一资源 标识符(URI)、RRWMTP消息基本框架、Request、Response、Entity，并对消息体 的签名和加密方法进行了规定；
点到点无线消息传输协议(P2PWMTP)：参照HTTP协议和SIP协议，定义了统 一资源标识符(URI)、会话邀请和消息转发、点到点消息传输(命令/应答方式)，并 对消息体的签名和加密方法进行了规定；
区域广播无线消息传输协议(DBWMTP)：定义了统一资源标识符(URI)、广播 请求、区域广播、AP广播(三种模式)；
群组无线消息传输协议(WGWMTP)：每个群组分配一个识别编号GID，定义 了统一资源标识符(URI)、启动群组通信、发送消息、转发消息(命令/应答方式)， 并对消息体的签名和加密方法进行了规定；
特别客户端消息传输：实现RRWMTP、P2PWMTP和WGWMTP，但可能连或 不连Wi-Fi用户机，签名和加密选择的密钥需要调整；
通用浏览器消息传输：可采用HTTP、S-HTTP、HTTP/TLS协议，连有Wi-Fi用 户机时可对消息进行签名、加密、签名验证和解密，不连时则无法用私钥签名和解密；
邮件无线传输：对消息体的签名和加密方法进行了规定。
4、消息传输安全和PKI服务
Wi-Fi用户机安全：内有一份用户证书，服务商根据产品批次生成一对签名密钥 和一对加密密钥，加密公钥包含在用户证书当中，并用服务商签名私钥对证书进行签 名。用户可通过Wi-Fi用户机申请自己的签名密钥对和加密密钥对，作为Wi-Fi用户 机专用密钥，私钥保存在用户机上，公钥则以X.509证书形式保存在PKI证书库中。 用户还可设置一个口令保护签名私钥，输入正确口令才能解锁和签名；
用户登录密码：通过Wi-Fi用户机设置，在没有Wi-Fi用户机时也能通过特别客 户端软件或者通用浏览器使用UID和用户密码登录系统；
特别客户端安全：用户可通过客户端软件申请自己的签名密钥对和加密密钥对， 作为特别客户端软件专用密钥(不连Wi-Fi用户机时使用)，私钥保存在客户端，公 钥则以X.509证书形式保存在PKI证书库中。用户还可设置一个口令保护签名私钥， 输入正确口令才能解锁和签名；
PKI服务：遵照X.509规范，定义了几种签名及加密公钥证书类型。
5、信息层次和信息分类
信息层次：包括国家(地区)、城市、地段、热点(信息点)，定义了编码方案， Wi-Fi AP机需根据所在区域位置设置具体的位置信息；
信息分类：区分为大类和细分类，大类包括公共信息、分类信息、即时信息、留 言信息、邮件信息、广告信息和应用信息，定义了编码方案，并对公共信息和分类信 息的细分类进行了详细定义。
本发明有益效果：
1)可以在全国甚至全世界范围建立统一的覆盖城镇商业中心、商务中心、社区 中心和交通中心的商用Wi-Fi网络，扩充灵活，使用方便。
2)能为人们提供灵活方便、价格低廉、安全可靠的数据通信平台。
3)除了提供信息发布、搜索和交流服务，提供考勤管理、买卖商城、办公及业 务管理、小区物业管理等应用服务，还能开发更多应用服务。
4)能有效调配社会资源，给人们的工作、学习和生活带来极大方便。
附图说明
图1为无线信息发布搜索交流应用系统结构框架图；
图2为Wi-Fi用户机结构框架图；
图3为用户信息卡结构和触点功能图；
图4为用户信息模块(单独做成产品)结构图；
图5为Wi-Fi AP机结构框架图；
图6为基于Wi-Fi用户机和Wi-Fi AP机的身份认证过程图；
图7为基于Wi-Fi用户机和特别客户端的身份认证过程图；
图8为基于Wi-Fi用户机和通用浏览器的身份认证过程图；
图9为基于用户口令和特别客户端的身份认证过程图；
图10为基于用户口令和通用浏览器的身份认证过程图；
图11为整数角色访问控制用户、角色等控制关系图；
图12为位或角色访问控制用户、角色等控制关系图；
图13为整数分级权限访问控制用户、角色等控制关系图；
图14为整数模块权限访问控制用户、角色等控制关系图；
图15为位或模块权限访问控制用户、角色等控制关系图；
图16为请求-响应无线消息传输模式图；
图17为点到点(P2P)无线消息传输模式图；
图18为按地域广播无线消息传输模式图；
图19为群组无线消息传输模式图；
图20为连Wi-Fi用户机，特别客户端请求-响应消息传输图；
图21为连Wi-Fi用户机，特别客户端点到点消息传输图；
图22为连Wi-Fi用户机，特别客户端群组消息传输图；
图23为不连Wi-Fi用户机，特别客户端请求-响应消息传输图。
图24为不连Wi-Fi用户机，特别客户端点到点消息传输图；
图25为不连Wi-Fi用户机，特别客户端群组消息传输图；
图26为连Wi-Fi用户机，通用浏览器应用消息传输图；
图27为不连Wi-Fi用户机，通用浏览器应用消息传输图；
图28为系统邮件服务部分结构及通信传输图；
图29为PKI服务系统结构框架图；
图30为Wi-Fi用户机软件功能模块结构及关系图；
图31为特别客户端软件功能模块结构及关系图；
图32为Wi-Fi AP机软件功能模块结构及关系图；
图33为认证服务器软件功能模块结构及关系图；
图34为应用服务器软件功能模块结构及关系图；
图35为Web服务器软件功能模块结构及关系图；
图36为通用浏览器软件功能模块结构及关系图；
图37为Wi-Fi用户机USB通信软件功能模块结构及关系图；
图38为邮件服务器软件功能模块结构及关系图；
图39为PKI应用服务器软件功能模块结构及关系图；
图40为数据库结构及关系图；
图41为应用服务软件简要设计图；
具体实施方式
下面结合附图对本发明进行进一步阐述。
一、系统结构设计说明
如图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-Fi AP机服务区域，手提电脑或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-Fi AP不一定能通过光纤连接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，Response Authenticator都使用同样的生成和计算规则。
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 Password Login、挑战应答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四种数据类型(RFC 2138)，另增加数据类型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 1 1 1 1 0-1 1 0-1 0-1 0-1 0-1 0-1 0-1 0 0-1 0 0 0 Request 0 0 0 0 0 1 0 0 0 0 0 0 0+ 0-1 0+ 0-1 0-1 Accept 0 0 0 0 0 0 0 0 0 0 0 0 0+ 0 0 0 0 Reject 0 0 0 0 0 0 0 0 0 0 0 0 0+ 0-1 0 0-1 0-1 Chal lenge 1 2 3 4 5 6 7 8 9 10 11 12 18 24 26 27 28 # User-Name User-Password Auth-Client-Type Auth-Client-IP-Address User-IP-Address Service-Type Wi-Fi-AP-Position MAC-Address SSID Producer Soft-Version Service-Provider-Signature Reply-Message State User-Access-Control Session-Timeout Idle-Timeout Attribute
以下是对上表表格内容含义的定义：
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 Transfer Protocol，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)回送给用户。如果对方不在线，则将消息通过request MESSAGE方法发给应用服务器，以后对方上线时可查询或者由服务器转发。用户结 束消息发送时则提交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 CRLF Command包括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为wgwmtp URI格式，方法为INVITE。服务器然后对请求进行核查，如果通不过，将给出适当 的Client Error响应(response)。如果能通过，则统计群组总用户数和在线用户数， 并给出成功response，其消息体中包括群组统计结果和当前在线用户清单等信息。接 下来服务器还要对群组通信服务进行初始化。管理员要结束群组通信时则提交request BYE方法。消息基本结构与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 CRLF Command包括MESSAGE。
general-header、entity-header、entity-body与RRWMTP基本一致。
消息接收者应答时只有一状态行(Status-Line)，格式如下：
Status-Line＝WGWMTP-Version SP Status-Code SP Reason-Phrase CRLF Status-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-Fi AP机等认证客户进行身份认证，系统应用程序则以各种通信传输协议为基础，它们 根据需要调用安全方面的上层模块。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机提供SNMP Agent程序，网络管理站可通过它对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-based module authority)，应用层协议采用P2PWMTP。
9.2群组通信
本系统提供的基本应用服务，访问控制类型可选择位或模块权限，登记用户权限 时需连上群组识别编号GID，应用层协议采用WGWMTP。
9.3消息留言
一般结合进其它应用中，采用RRWMTP或HTTP协议。
9.4电子邮件
以SMTP、POP3、IMAP4协议为基础，访问控制类型选择位或模块权限。
9.5公共信息发布、检索和浏览
用户可以自由地检索和浏览公共信息，但发布公共信息的权限要受严格控制，一 般从公共信息类别和区域位置两个方面进行限制，访问控制类型可选择位或角色(2 bit-or-based role)。Wi-Fi用户机、特别客户端以RRWMTP协议为基础，通用浏览器 则用HTTP协议。
9.6分类信息发布、检索和浏览
用户可以检索和浏览分类信息，并可根据自己的需要选择区域位置发布分类信 息。考虑到需要管理人员进行监控，访问控制类型可选择整数分级权限(3 integer-based grade authority)。Wi-Fi用户机、特别客户端以RRWMTP协议为基础， 通用浏览器和Web服务器则用HTTP协议。
9.7广告信息区域广播
用户进入指定区域时将被动接收AP广播，但广告信息的发布由服务商授权控制， 一般是对区域位置进行限制，访问控制类型选择位或角色，并在DBWMTP协议基础 上设计开发。
9.8企业单位考勤管理
为企业单位提供的应用服务，企业需以实体群组进行登记，并为企业分配一个群 组识别编号GID，企业所属员工则与企业GID关联。企业办公所在区域需安装Wi-Fi AP机，每个员工都配置一台Wi-Fi用户机，设置用户访问控制权限时，应指定Wi-Fi AP机具体位置为企业办公区域的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协议。
一、系统结构设计说明
如图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-Fi AP机服务区域，手提电脑或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-Fi AP不一定能通过光纤连接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，Response Authenticator都使用同样的生成和计算规则。
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 Password Login、挑战应答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四种数据类型(RFC 2138)，另增加数据类型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 1 1 1 1 0-1 1 0-1 0-1 0-1 0-1 0-1 0-1 0 0-1 0 0 0 Request 0 0 0 0 0 1 0 0 0 0 0 0 0+ 0-1 0+ 0-1 0-1 Accept 0 0 0 0 0 0 0 0 0 0 0 0 0+ 0 0 0 0 Reject 0 0 0 0 0 0 0 0 0 0 0 0 0+ 0-1 0 0-1 0-1 Chal lenge 1 2 3 4 5 6 7 8 9 10 11 12 18 24 26 27 28 # User-Name User-Password Auth-Client-Type Auth-Client-IP-Address User-IP-Address Service-Type Wi-Fi-AP-Position MAC-Address SSID Producer Soft-Version Service-Provider-Signature Reply-Message State User-Access-Control Session-Timeout Idle-Timeout Attribute
以下是对上表表格内容含义的定义：
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 Transfer Protocol，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)回送给用户。如果对方不在线，则将消息通过request MESSAGE方法发给应用服务器，以后对方上线时可查询或者由服务器转发。用户结 束消息发送时则提交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 CRLF Command包括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为wgwmtp URI格式，方法为INVITE。服务器然后对请求进行核查，如果通不过，将给出适当 的Client Error响应(response)。如果能通过，则统计群组总用户数和在线用户数， 并给出成功response，其消息体中包括群组统计结果和当前在线用户清单等信息。接 下来服务器还要对群组通信服务进行初始化。管理员要结束群组通信时则提交request BYE方法。消息基本结构与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 CRLF Command包括MESSAGE。
general-header、entity-header、entity-body与RRWMTP基本一致。
消息接收者应答时只有一状态行(Status-Line)，格式如下：
Status-Line＝WGWMTP-Version SP Status-Code SP Reason-Phrase CRLF Status-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-Fi AP机等认证客户进行身份认证，系统应用程序则以各种通信传输协议为基础，它们 根据需要调用安全方面的上层模块。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机提供SNMP Agent程序，网络管理站可通过它对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-based module authority)，应用层协议采用P2PWMTP。
9.2群组通信
本系统提供的基本应用服务，访问控制类型可选择位或模块权限，登记用户权限 时需连上群组识别编号GID，应用层协议采用WGWMTP。
9.3消息留言
一般结合进其它应用中，采用RRWMTP或HTTP协议。
9.4电子邮件
以SMTP、POP3、IMAP4协议为基础，访问控制类型选择位或模块权限。
9.5公共信息发布、检索和浏览
用户可以自由地检索和浏览公共信息，但发布公共信息的权限要受严格控制，一 般从公共信息类别和区域位置两个方面进行限制，访问控制类型可选择位或角色(2 bit-or-based role)。Wi-Fi用户机、特别客户端以RRWMTP协议为基础，通用浏览器 则用HTTP协议。
9.6分类信息发布、检索和浏览
用户可以检索和浏览分类信息，并可根据自己的需要选择区域位置发布分类信 息。考虑到需要管理人员进行监控，访问控制类型可选择整数分级权限(3 integer-based grade authority)。Wi-Fi用户机、特别客户端以RRWMTP协议为基础， 通用浏览器和Web服务器则用HTTP协议。
9.7广告信息区域广播
用户进入指定区域时将被动接收AP广播，但广告信息的发布由服务商授权控制， 一般是对区域位置进行限制，访问控制类型选择位或角色，并在DBWMTP协议基础 上设计开发。
9.8企业单位考勤管理
为企业单位提供的应用服务，企业需以实体群组进行登记，并为企业分配一个群 组识别编号GID，企业所属员工则与企业GID关联。企业办公所在区域需安装Wi-Fi AP机，每个员工都配置一台Wi-Fi用户机，设置用户访问控制权限时，应指定Wi-Fi AP机具体位置为企业办公区域的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协议。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 一种纺纱机喂给罗拉上除尘辊废纱收集系统 | 2020-05-12 | 589 |
| 圆织机废纱管处理器 | 2020-05-11 | 257 |
| 气流纺棉纱的浆纱废水循环利用方法及其装置 | 2020-05-12 | 511 |
| 耐候性纺织废纱清洁器 | 2020-05-12 | 562 |
| 纺织废纱清洁器 | 2020-05-11 | 698 |
| 自由端型纺纱机和从自由端型纺纱机排出纱线废料的方法 | 2020-05-12 | 367 |
| 纱线染织废水处理装置 | 2020-05-12 | 3 |
| 一种袜机废纱筒 | 2020-05-13 | 389 |
| 无废边纱装置 | 2020-05-13 | 154 |
| 废边纱导向装置 | 2020-05-13 | 554 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
废纱热门专利
QQ群二维码
意见反馈
意见反馈