CN106954216B - 基于802.1x协议的认证方法及系统 - Google Patents

基于802.1x协议的认证方法及系统 Download PDF

Info

Publication number
CN106954216B
CN106954216B CN201710295109.6A CN201710295109A CN106954216B CN 106954216 B CN106954216 B CN 106954216B CN 201710295109 A CN201710295109 A CN 201710295109A CN 106954216 B CN106954216 B CN 106954216B
Authority
CN
China
Prior art keywords
party
authentication
client
verification
password
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710295109.6A
Other languages
English (en)
Other versions
CN106954216A (zh
Inventor
高原
党艳平
于世刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Linkdood Technologies Sdn Bhd
Original Assignee
Linkdood Technologies Sdn Bhd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Linkdood Technologies Sdn Bhd filed Critical Linkdood Technologies Sdn Bhd
Priority to CN201710295109.6A priority Critical patent/CN106954216B/zh
Publication of CN106954216A publication Critical patent/CN106954216A/zh
Application granted granted Critical
Publication of CN106954216B publication Critical patent/CN106954216B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明提供了基于802.1X协议的认证方法及系统，涉及通讯领域。本发明提供的基于802.1X协议的认证方法，采用设置防第三方标记的方式，其具体通过在发送供验证使用的用户名或发送供验证使用的密码时，将防第三方标记也一同发送给了认证服务器进行认证，其中，不同类型的客户端中所存储的防第三方标记不同。从而保证了不同类型的客户端是不能相互借用的(防第三方标记不同)，进而避免了黑客在知晓了用户的账号和密码后，就可以任意的使用用户的身份进行认证的问题。

Description

基于802.1X协议的认证方法及系统
技术领域
本发明涉及通讯领域，具体而言，涉及基于802.1X协议的认证方法及系统。
背景技术
802.1x协议是基于Client/Server的访问控制和认证协议。它可以限制未经授权的用户/设备通过接入端口(access port)访问LAN/WLAN。在获得交换机或LAN提供的各种业务之前，802.1x对连接到交换机端口上的用户/设备进行认证。在认证通过之前，802.1x只允许EAPoL(基于局域网的扩展认证协议)数据通过设备连接的交换机端口；认证通过以后，正常的数据可以顺利地通过以太网端口。
相关技术中所提供的标准802.1x协议通常被认为是一种普适性的技术，其能够适用于大部分的场景，但发明人经过实际使用后发现，上述技术并不能很好的适用在某些具体的场景。
发明内容
本发明的目的在于提供基于802.1X协议的认证方法，以提高认证的安全性。
第一方面，本发明实施例提供了基于802.1X协议的认证方法，包括：
客户端向接入设备发起认证请求；
接入设备向客户端发送询问通知；
客户端通过接入设备向认证服务器发送第一应答消息，第一应答消息中携带有验证用户名；
认证服务器对验证用户名进行第一验证；
若第一验证通过，则认证服务器通过接入设备向客户端发送随机生成的加密字；
客户端通过接入设备向认证服务器发送第二应答消息，第二应答消息中携带有验证密码；验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，和/或，验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端中所存储的防第三方标记不同；
认证服务器对验证密码进行第二验证，以确定客户端是否通过认证。
结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，步骤认证服务器对第一应答消息进行第一验证包括：
认证服务器提取第一应答消息中的防第三方标记；
认证服务器验证防第三方标记是否为真，若是，则第一验证通过。
结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，验证用户名中至少携带有防第三方标记、实际用户名和实际密码；
步骤认证服务器对验证用户名进行第一验证包括：
认证服务器分别防第三方标记、实际用户名和实际密码进行验证，若防第三方标记、实际用户名和实际密码均为真，则第一验证通过。
结合第一方面，本发明实施例提供了第一方面的第三种可能的实施方式，其中，携带在验证用户名中的防第三方标记、实际用户名和实际密码均是分别独立的进行过加密的，且客户端至少使用了两种不同的加密算法分别对防第三方标记、实际用户名和实际密码中的至少两个进行了加密；
步骤认证服务器对验证用户名进行第一验证还包括：
认证服务器对加密后的防第三方标记、实际用户名和实际密码进行解密。
结合第一方面，本发明实施例提供了第一方面的第四种可能的实施方式，其中，防第三方标记、实际用户名和实际密码是按照预设的排列格式，排列在验证用户名中的；排列格式包括：排列次序，和/或间隔符的设置位置，和/或间隔符的表达形式；
步骤认证服务器对验证用户名进行第一验证还包括：
认证服务器对验证用户名中防第三方标记、实际用户名和实际密码的排列格式进行验证，若验证通过，则执行步骤认证服务器分别防第三方标记、实际用户名和实际密码进行验证。
结合第一方面，本发明实施例提供了第一方面的第五种可能的实施方式，其中，还包括：
客户端分别使用预先存储在本地的第一加密算法和预设的非对称加密算法对对用户输入的实际密码进行加密，得到验证密码；使用非对称算法进行加密时，使用加密字。
结合第一方面，本发明实施例提供了第一方面的第六种可能的实施方式，其中，步骤认证服务器对验证密码进行第二验证包括：
认证服务器分别使用预先存储在本地的第二加密算法和预设的非对称加密算法对预先存储在本地的实际密码进行加密，得到参考密码；使用非对称算法进行加密时，使用加密字；
认证服务器比较参考密码和验证密码是否相同，若相同，则客户端通过认证。
结合第一方面，本发明实施例提供了第一方面的第七种可能的实施方式，其中，对验证用户名中的防第三方标记、实际用户名和实际密码进行加密所使用的加密算法和对验证密码中的实际密码进行加密所使用的加密算法不同。
结合第一方面，本发明实施例提供了第一方面的第八种可能的实施方式，其中，还包括：
客户端向第三方平台发起下载请求，下载请求中携带有验证信息，验证信息包括以下的一种或多种，类别信息、地域信息、时间信息；
第三方平台将与下载请求中的验证信息相对应的防第三方标记向客户端发送。
结合第一方面，本发明实施例提供了第一方面的第九种可能的实施方式，其中，在步骤第三方平台将与下载请求中的验证信息相对应的防第三方标记向客户端发送前还包括：
第三方平台将与下载请求中的验证信息相对应的防第三方标记向认证服务器发送。
结合第一方面，本发明实施例提供了第一方面的第十种可能的实施方式，其中，步骤第三方平台将与下载请求中的验证信息相对应的防第三方标记向客户端发送包括：
第三方平台将更新数据包向安装客户端的电子设备上发送，更新数据包中携带有防第三方标记和客户端的安装包。
结合第一方面，本发明实施例提供了第一方面的第十一种可能的实施方式，其中，还包括：
安全用户端将获取到的防第三方标记和对应的验证信息写入配置文件中；
安全用户端将配置文件上传至第三方平台。
结合第一方面，本发明实施例提供了第一方面的第十二种可能的实施方式，其中，还包括：
第三方平台在接收到调整指令后，对本地的防第三方标记进行更新；调整指令是第三方平台每隔预定时间生成的，或调整指令是由安全用户端所发出的，且调整指令中携带有用于形成更新后的防第三方标记的文件；
第三方平台将更新后的防第三方标记向目标客户端发送；目标客户端是第三方平台曾发送过更新前的防第三方标记的客户端。
第二方面，本发明实施例还提供了基于802.1X协议的认证方法，包括：
向接入设备发起认证请求；
在接收到接入设备所返回的询问通知后，通过接入设备向认证服务器发送第一应答消息，以使认证服务器对验证用户名进行第一验证；第一应答消息中携带有验证用户名；
在接收到加密字后，客户端通过接入设备向认证服务器发送第二应答消息，以使认证服务器对验证密码进行第二验证，以确定客户端是否通过认证；第二应答消息中携带有验证密码；验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，和/或，验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端所对应的防第三方标记不同；加密字是认证服务器对验证用户名进行第一验证，且第一验证通过后，由认证服务器随机生成的。
第二方面，本发明实施例还提供了基于802.1X协议的认证系统，包括：依次顺序通讯连接的客户端、接入设备和认证服务器；
客户端，用于向接入设备发起认证请求；并通过接入设备向认证服务器发送第一应答消息，第一应答消息中携带有验证用户名；以及，通过接入设备向认证服务器发送第二应答消息，第二应答消息中携带有验证密码；验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，和/或，验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端所对应的防第三方标记不同；
接入设备，用于向客户端发送询问通知；和转发第一应答消息，以及转发第二应答消息；
认证服务器，用于对验证用户名进行第一验证；若第一验证通过，则认证服务器通过接入设备向客户端发送随机生成的加密字；以及，对验证密码进行第二验证，以确定客户端是否通过认证。
本发明实施例提供的基于802.1X协议的认证方法，采用设置防第三方标记的方式，与现有技术中只通过非对称加密的方式来进行安全性的提高，导致安全性提高的有限相比，其通过在发送供验证使用的用户名或发送供验证使用的密码时，将防第三方标记也一同发送给了认证服务器进行认证，其中，不同类型的客户端中所存储的防第三方标记不同。从而保证了不同类型的客户端是不能相互借用的(防第三方标记不同)，进而避免了黑客在知晓了用户的账号和密码后，就可以任意的使用用户的身份进行认证的问题。
为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本发明实施例所提供的基于802.1X协议的认证方法的基本流程图；
图2示出了本发明实施例所提供的基于802.1X协议的认证方法的网络架构图；
图3示出了相关技术中的标准802.1X协议的认证方法；
图4示出了本发明实施例所提供的基于802.1X协议的认证方法的实例的网络架构图。
具体实施方式
下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
相关技术中，已经存在一般的标准的802.1x协议，该协议的适用范围很广泛，由于采用了非对称加密技术，因此，能够保证一定的安全性。
相关技术中，标准的802.1x协议的认证方法如下：
S1.当用户有上网需求时打开802.1X客户端程序，输入已经申请、登记过的用户名和口令(密码)，发起连接请求。此时，客户端程序将发出请求认证的报文给交换机，开始启动一次认证过程。
S2.交换机收到请求认证的数据帧后，将发出一个请求帧要求用户的客户端程序将输入的用户名送上来。
S3.客户端程序响应交换机发出的请求，将用户名信息通过数据帧送给交换机。交换机将客户端送上来的数据帧经过封包处理后送给认证服务器进行处理。
S4.认证服务器收到交换机转发上来的用户名信息后，将该信息与数据库中的用户名表相比对，找到该用户名对应的口令信息，用随机生成的一个加密字对它进行加密处理，同时也将此加密字传送给交换机，由交换机传给客户端程序。
S5.客户端程序收到由交换机传来的加密字后，用该加密字对口令部分进行加密处理(此种加密算法通常是不可逆的)，并通过交换机传给认证服务器。
S6.认证服务器将送上来的加密后的口令信息和其自己经过加密运算后的口令信息进行对比，如果相同，则认为该用户为合法用户，反馈认证通过的消息，并向交换机发出打开端口的指令，允许用户的业务流通过端口访问网络。否则，反馈认证失败的消息，并保持交换机端口的关闭状态，只允许认证信息数据通过而不允许业务数据通过。
发明人发现，传统的802.1x协议主要是通过这种非对称加密的形式起到提高安全性的目的，但当非法人员在知晓了用户的用户名和密码之后，可以从任意的一个资源点下载到802.1x协议的客户端，之后直接使用该客户端登录即可，也就是，传统的802.1x协议依旧是通过账号和密码来达到防止第三方恶意登录的目的的，通过设置了非对称加密的手段，避免了第三方通过网络手段截取密码，但如果第三方提前知晓了密码的话，则无法起到保护的作用。也就是，传统技术中，第三方在知晓用户的账号和密码后，可以使用任意的一个客户端进行登录，这导致用户的账号的安全性受到了威胁。
针对该种情况，本申请提供了基于802.1X协议的认证方法，如图1所示，该方法所应用到的网络架构如图2所示，该方法包括：
S101，客户端向接入设备发起认证请求；
S102，接入设备向客户端发送询问通知；
S103，客户端通过接入设备向认证服务器发送第一应答消息，第一应答消息中携带有验证用户名；
S104，认证服务器对验证用户名进行第一验证；
S105，若第一验证通过，则认证服务器通过接入设备向客户端发送随机生成的加密字；
S106，客户端通过接入设备向认证服务器发送第二应答消息，第二应答消息中携带有验证密码；验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，和/或，验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端中所存储的防第三方标记不同；
S107，认证服务器对验证密码进行第二验证，以确定客户端是否通过认证。
其中，步骤S101和步骤S102与一般的802.1X协议中的流程基本相同，步骤S101是在用户的操作下，由终端中的客户端向接入设备发起的，而步骤S102则是由交换机一类的具有转发功能的设备完成的。即接入设备可以指交换机，也可以是某些智能电子设备。
而后，步骤S103中，客户端向服务器反馈了第一应答消息，该第一应答消息汇总携带了验证用户名；以供认证服务器在步骤S104中对该验证用户名进行验证，验证通过后，在步骤S105中，认证服务器向客户端返回了随机生成的加密字。步骤S106中，客户端使用该加密字对密码进行了加密，并将加密后的密码发送给了认证服务器，以完成整体的认证。
需要说明的是，步骤S104中的第一验证，通常指的是验证用户名是否是真实的(是否进行过注册)。
步骤S103和步骤S106中分别向认证服务器中发送了第一应答消息和第二应答消息，这两个应答消息中至少有一个携带了防第三方标记，进而使得认证服务器可以在步骤S104或步骤S107中，针对该防第三方标记进行校验。
如客户端在第一响应请求中携带了防第三方标记(即验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的)，则步骤S104，认证服务器对第一应答消息进行第一验证包括：
认证服务器提取第一应答消息中的防第三方标记；
认证服务器验证防第三方标记是否为真，若是，则第一验证通过。
当然，还可以是在此基础上增加用户名的判断，也就是步骤S104，认证服务器对第一应答消息进行第一验证包括：
认证服务器提取第一应答消息中的防第三方标记；
认证服务器分别验证防第三方标记是否为真，以及验证实际用户名是否为真(如是否已注册)，若防第三方标记为真，且实际用户名为真，则第一验证通过。
如客户端在第二响应请求中携带了防第三方标记(即第二应答消息中携带有验证密码；验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的)，则步骤S107，认证服务器对验证密码进行第二验证，以确定客户端是否通过认证包括：
用户分别对认证服务器分别防第三方标记、实际用户名和实际密码进行验证，若防第三方标记、实际用户名和实际密码均为真，则第一验证通过。
此处，需要说明的是，实际用户名和实际密码均是用户在操作客户端进行注册的时候与注册商(可能是认证服务器的运营商，也可能是独立的第三方)约定好的，用户在认证之前只需要向客户端中输入实际用户名和实际密码即可，用户通常是无法知晓防第三方标记的内容，以及如何生成验证密码的。进而达到了保密的作用。
当然，本方案在实现的时候，可以是只在在第一响应请求中携带防第三方标记，也可以是只在在第二响应请求中携带防第三方标记，还可以是同时在第一响应请求和第二响应请求中均携带防第三方标记。对于认证服务器而言，在判断防第三方标记前，首先应当确定与该客户端相对应的标准防第三方标记，而后，再判断客户端发送来的防第三方标记与标准防第三方标记是否相同，进而确定本次验证是否通过。
当同时在第一响应请求和第二响应请求中均携带防第三方标记的情况下，可以是分别在第一响应请求和第二响应请求中所携带的防第三方标记的内容不同，即对于同一类客户端而言，可以将完成的防第三方标记拆成两段(即防第三方标记包括第一个第三方标记段和第二个第三方标记段)，而后，按照约定好的规则，执行步骤S103时，在第一应答消息中携带第一个防第三方标记段，并且在执行步骤S106时，在第二应答消息中携带第二个防第三方标记段，进而，在步骤S104和步骤S107中，认证服务器除了可以分别对这两个防第三方标记段的内容进行验证外，还可以对接收到这两个防第三方标记段的接收顺序进行验证(是否在第一应答消息中携带了第一个防第三方标记段，以及，是否在第二应答消息中携带第二个防第三方标记段)，如果顺序验证也通过，才确定客户端通过了认证。
上述方案中，如果在第一响应请求中携带了防第三方标记，则认证服务器必然会在步骤S104中，对防第三方标记进行第一验证，如果第一验证通过了，则会执行步骤S105，如果第一验证失败了，则会判断认证失败，并终止流程。
由于防第三方标记有很多种，并且，不同类型的客户端所对应的防第三方标记是不同的，因此，从某一个角度来看防第三方标记，该防第三方标记近似于用对客户端的一个分类编码，进而认证服务器可以依据该防第三方标记来确定客户端是否有权限。这也就保证了如果黑客随意的拿到一个客户端的安装包，并且安装了客户端，但由于该客户端中没有防第三方标记或者该客户端中的防第三方标记是错误的，最终会导致黑客无法通过验证。
在某种具体的场景下，认证服务器中可以预存如下的表格：
表1
编号 客户端类别 防第三方标记
1 第一类 DWR323
2 第二类 J5GE
3 第三类 5HBV
4 第四类 84JFR
由表1可见，不同类别的用户所对应的防第三方标记是不同的，因此认证服务器可以以此来判断该次认证是否允许通过。
本方案所提供的方法中，并没有删除原有的802.1X协议中应有的步骤，而是在其基础上增加了步骤，因此，改动操作量较小，也更容易进行推广。
如前文中的说明，步骤S104，认证服务器对验证用户名进行第一验证的步骤，可以是认证服务器分别防第三方标记、实际用户名和实际密码进行验证，若防第三方标记、实际用户名和实际密码均为真，则第一验证通过。
为了进一步提高安全性，可以是客户端生成第一应答消息的时候，预先对第一应答消息中的防第三方标记、实际用户名和实际密码分别进行加密的，进而保证在传输第一应答消息的过程中，如果被黑客所截取到，也不会轻易泄露防第三方标记、实际用户名和实际密码。
为了更进一步提高安全性，应当是客户端至少使用了两种不同的加密算法分别对防第三方标记、实际用户名和实际密码中的至少两个进行了加密。也就是对这三个数据(防第三方标记、实际用户名和实际密码)分别进行加密的时候，应当是采用了两种不同的加密算法分别对防第三方标记、实际用户名和实际密码中的至少两个进行加密。其中，两种加密算法指的是加密原理相同，但加密时使用的具体参数的取值不同的两个加密算法；也可以指加密原理不同的两个加密算法。类似的多种(三种及以上)加密算法也可以按照这种方式理解。
下面以加密算法为两种的情况进行说明，如在使用加密算法A和加密算法B对防第三方标记、实际用户名和实际密码进行加密的话，则可以是使用加密算法A分别对防第三方标记和实际用户名进行加密，和使用加密算法B单独为实际密码进行加密。还可以是使用加密算法A分别对防第三方标记和实际用户名进行加密，之后，使用加密算法B分别为实际密码和经过加密算法A加密后的防第三方标记进行加密(此时，防第三方标记分别经过加密算法A和加密算法B进行过加密，加密程度更高，保密性更强)。
类似的，如果是使用三种加密算法分别对这三个数据进行加密，则可以是每一种加密算法加密一个数据，且每个加密算法只用一次。
如果使用四种或者更多种加密算法对这三个数据进行加密的话，则必然会有至少一个数据会被两种不同的加密算法进行加密。入共有加密算法A-D这四种加密算法，那么可以是先分别使用加密算法A-C对三个数据进行加密，而后，再使用加密算法D对加密后的防第三方标记和实际用户名再进行加密。
由于这种重叠加密的方式更能够起到保证数据安全的作用，因此，本方案中，携带在验证用户名中的防第三方标记、实际用户名和实际密码均是分别独立的进行过加密的，且客户端至少使用了两种不同的加密算法分别对防第三方标记、实际用户名和实际密码中的至少两个进行了加密；同时，防第三方标记、实际用户名和实际密码中的至少一个是使用至少两个加密密码进行过加密的。
作为一种典型的优选例，本方案优选使用的加密算法为两种，并且，使用第一种加密算法对防第三方标记、实际用户名进行加密，使用第二种加密算法对实际密码和使用第一种加密算法加密后的防第三方标记进行加密。
相对应的，如果认证服务器接收到的是加密后的验证用户名，则认证服务器必然需要进行反向解密，解密的过程与加密的过成功是相对应的，此处不再过多描述，但解密和加密的方式均是预先分别存储在认证服务器和客户端中的。
上述内容介绍了通过加密来提高整体安全性的方式，还可以是从三个数据的排列格式的角度来提高安全性，即防第三方标记、实际用户名和实际密码是按照预设的排列格式，排列在验证用户名中的；排列格式包括：排列次序，和/或间隔符的设置位置，和/或间隔符的表达形式；
相对应的，步骤认证服务器对验证用户名进行第一验证还包括：
认证服务器对验证用户名中防第三方标记、实际用户名和实际密码的排列格式进行验证，若验证通过，则执行步骤认证服务器分别防第三方标记、实际用户名和实际密码进行验证。
其中，排列次序指的是防第三方标记、实际用户名和实际密码在验证用户名中的前后顺序，如可以预先约定，三个数据按照如下的前后顺序排列：防第三方标记、实际用户名、实际密码；还可以是防第三方标记、实际密码、实际用户名；又或者是实际用户名、防第三方标记、实际密码。
间隔符的设置位置指的是，验证用户名中除了记载有防第三方标记、实际用户名和实际密码，还可以记载有与这三者无关的符号，这个符号起到的隔断的作用，如可以在相邻的两个数据之间架设间隔符，即间隔符的设置位置是相邻的两个数据之间，这样认证服务器通过间隔符能够更好的区分这三个数据，从而避免误认。间隔符还可以是设置在某一个数据之中，当然，为了避免认证错误，间隔符一般是不需要加密的。
间隔符也可以是有多种形式，如设置在第一个数据和第二个数据之间的间隔符与设置在第二个数据和第三个数据之间的间隔符是不相同的，这也就是间隔符为多个的时候，间隔符的表达形式不同。还可以是对于不同种类的客户端，间隔符的表达形式不相同。
上述这三种方式(防第三方标记、实际用户名和实际密码排列次序、间隔符的设置位置和间隔符的表达形式)可以同时使用，也可以是使用其中的任意两个，还可以是三个全部使用。
前述内容中介绍了对验证用户名中的三种数据进行加密的方式，与之类似的，客户端可以对验证密码中所携带的实际密码进行加密。即，客户端分别使用预先存储在本地的第一加密算法和预设的非对称加密算法对对用户输入的实际密码进行加密，得到验证密码；使用非对称算法进行加密时，使用加密字。
此处的第一加密算法优选是与非对称加密算法不同的算法。
相对应的，步骤认证服务器对验证密码进行第二验证包括：
认证服务器分别使用预先存储在本地的第二加密算法和预设的非对称加密算法对预先存储在本地的实际密码进行加密，得到参考密码；使用非对称算法进行加密时，使用加密字；
认证服务器比较参考密码和验证密码是否相同，若相同，则客户端通过认证。
需要说明的是，第一加密算法和第二加密算法一般是相同的。本方案所提供的方案，在传统的802.1X协议使用非对称加密算法(MD5加密算法)的基础上，增加了第一加密算法和第二加密算法，进一步提高了安全性。
并且，使用第一加密算法和使用非对称加密算法对实际密码的加密顺序可以任意调整，可以是先使用第一加密算法，再使用非对称加密算法，也可以是颠倒过来。类似的使用第二加密算法和使用非对称加密算法对实际密码的加密顺序可以任意调整。
为了进一步提高整体安全性，优选的，对验证用户名中的防第三方标记、实际用户名和实际密码进行加密所使用的加密算法和对验证密码中的实际密码进行加密所使用的加密算法不同。
即，对验证用户名中的防第三方标记、实际用户名和实际密码进行加密所使用过的加密算法中的任一个加密算法都不与对验证密码中的实际密码进行加密所使用的加密算法相同。以此，来保证安全性。
需要说明的是，通常情况下，步骤S106，客户端通过接入设备向认证服务器发送第二应答消息在执行时，接入设备除了转发第二应答消息外，还会将验证用户名发送给认证服务器。也就是，在步骤S103中，接入设备向认证服务器发送第一应答消息的时候，将第一应答消息中的验证用户名保存在了本地，并且在步骤S106中，向认证服务器转发第二应答消息的时候，也将保存在本地的验证用户名发送给了认证服务器，以供认证服务器使用。
下面对防第三方标记进行说明。
本申请所提供的方法，还包括如下步骤：
客户端向第三方平台发起下载请求，下载请求中携带有验证信息，验证信息包括以下的一种或多种，类别信息、地域信息、时间信息；
第三方平台将与下载请求中的验证信息相对应的防第三方标记向客户端发送。
也就是，防第三方标记是采用第三方平台下发的方式发送给了客户端，第三方平台一般是独立于认证服务器的平台，以免内部数据混乱。如前文中所说，对于不同的类型的用户，其所使用的防第三方标记是不相同的，因此，在请求防第三方标记的时候，应当上交自身的验证信息，以供第三方平台判断自己是哪个类型的用户，判断的依据有类别信息、地域信息、时间信息，具体可以使用这三种信息中的任意一种或多种。
而后，第三方平台仅将与下载请求中的验证信息相对应的防第三方标记向客户端发送，其他类别所对应的防第三方标记则不会像该客户端提供，以免信息泄露。
由于进行802.1X协议认证的主体是认证服务器，因此，在认证服务器进行认证之前也需要得到该防第三方标记，并且，为了保证认证的准确性，应当保证防第三方标记是先发给认证服务器的，以免客户端已经开始了认证，而认证服务器还没有得到该防第三方标记，进而避免导致原本应当通过的认证却被拒绝的情况。
即，在步骤第三方平台将与下载请求中的验证信息相对应的防第三方标记向客户端发送前还包括：
第三方平台将与下载请求中的验证信息相对应的防第三方标记向认证服务器发送。
具体的，为了提高数据的安全性，应当将防第三方标记和一般的客户端安装包捆绑在一起下发给用户，步骤第三方平台将与下载请求中的验证信息相对应的防第三方标记向客户端发送包括：
第三方平台将更新数据包向安装客户端的电子设备上发送，更新数据包中携带有防第三方标记和客户端的安装包。
这样，便加快了防第三方标记下发的准确性和快捷性。即第三方平台可以预先将客户端安装包和对应的防第三方标记写在同一个更新数据包中，从而形成多个更新数据包，每个更新数据包中所携带的客户端安装包均不相同，且每个更新数据包中所携带的防第三方标记均不相同。这样，第三方平台可以将每个更新数据包预先发送给指定的下级平台(如每个下级平台只发送一个或，指定的几个更新数据包)，而后又多个下级平台负责更新数据包的发放，并且，由于每个下级平台都无法知晓全部的更新数据包，从而即分担了第三方平台的压力(下载更新数据包的网络流量压力)，有保证了认证的安全性。其中，本申请所描述的客户端安装包指的是原始安装包(在电子设备上没有客户端的时候进行安装的安装包)，也可以指的是升级包(在电子设备上没有旧版本客户端的时候进行安装的安装包)。
防第三方标记有两种不同的生成方式，第一种方式是由第三方平台随机生成，第二种方式是由用户端(可以是客户端的载体)来生成。考虑到安全性，应当将生成防第三方标记的任务交给值得信任的安全用户端来执行。
即，本申请所提供的方法还包括：
安全用户端将获取到的防第三方标记和对应的验证信息写入配置文件中；
安全用户端将配置文件上传至第三方平台。
除了单纯的第三方标记的生成，还可以通过及时的修改防第三方标记来达到提高安全性的作用，进而，本申请所提供的方法还包括：
第三方平台在接收到调整指令后，对本地的防第三方标记进行更新；调整指令是第三方平台每隔预定时间生成的，或调整指令是由安全用户端所发出的，且调整指令中携带有用于形成更新后的防第三方标记的文件；
第三方平台将更新后的防第三方标记向目标客户端发送；目标客户端是第三方平台曾发送过更新前的防第三方标记的客户端。
其中，调整指令中携带有用于形成更新后的防第三方标记的文件所指的情况有两种。
第一种情况，调整指令中直接携带有防第三方标记的内容，当然，还应当携带有该防第三方标记所对应的验证信息，验证信息包括以下的一种或多种，类别信息、地域信息、时间信息。而后，第三方平台可以直接使用调整指令中的防第三方标记来替代原有的防第三方标记。
第二种情况，调整指令中携带了生成新的防第三方标记的线索，如调整指令中携带了基本编码的号码，第三方平台中存储有列表，且列表中记载了基本编码的号码和对应的内容。具体如下表所示，
表2
基本编码的号码 基本编码的内容
1 G31G2YH
2 QWD1HM68
3 GB3145N
4 3NE50P
5 3N78]8
而后，第三方平台在接收到了调整指令中的基本编码的号码后，根据该号码在列表中查找号码所赌赢的基本编码的内容，并将查找到的基本编码的内容作为新的防第三方标记。通过此种方式，保证了安全用户端和第三方平台均没有彻底的防第三方标记的修改权，各自只有一部分权利，且双方相互制约，从而保证了安全性。
优选的，第三方平台应当每隔一定的时间更新一次本地的列表，以对列表中的，基本编码的号码，和/或基本编码的内容进行调整。
下面，以一个具体的实例来说明本申请所提供的方法，如图4所示，示出了相应的网络架构，该方法包括如下步骤：
步骤1，用户A操作用户端A在web平台(第三方平台)上输入防第三方标记；
步骤2，第三方平台对防第三方标记和客户端的原始安装包打包成新安装包；
步骤3，用户B操作用户端B访问web平台，请求下载新安装包；
步骤4，web平台将新安装包下发给用户端B；
步骤5，用户端B使用新安装包进行安装，在用户端B上形成了客户端；
步骤6，客户端在用户B的操作(输入了实际用户名和实际密码)下，向交换机(接入设备)发起认证请求；
步骤7，接入设备向客户端发送询问通知，以让客户端提供用户名；
步骤8，客户端B使用加密算法A对实际用户名进行加密，得到字符串A，使用加密算法B对实际密码进行加密，得到字符串B，使用加密算法C对防第三方标记进行加密，得到字符串C，而后，使用加密算法D对字符串B和C进行加密得到了字符串E；并将字符串A和E组成了验证用户名；
步骤9，客户端将验证用户名发送给交换机；
步骤10，交换机将验证用户名存储在本地，并将验证用户名发送给认证服务器；
步骤11，认证服务器按照步骤8中加密的过程的逆过程进行解密，并分别对实际用户名、实际密码和防第三方标记进行验证，如这三个验证均通过，则执行步骤12；否则，则向交换机返回认证失败，并终止流程；
步骤12，认证服务器随机生成加密字；
步骤13，认证服务器将加密字发送给交换机；
步骤14，交换机将加密字发送给客户端；
步骤15，客户端使用加密算法E对用户输入的实际密码进行加密，得到字符串F，再使用MD5加密技术，参照步骤14得到的加密字的内容对字符串F进行加密，得到验证密码；
步骤16，客户端将验证密码发送给交换机；
步骤17，交换机将验证密码和步骤10中保存的验证用户名发送给认证服务器；
步骤18，认证服务器按照步骤8中加密的过程的逆过程进行解密，并分别对实际用户名、实际密码和防第三方标记进行验证，如这三个验证均通过，则执行步骤19；否则，则向交换机返回认证失败，并终止流程；
步骤19，认证服务器使用加密算法E对预存在本地的实际密码进行加密，得到字符串G，再使用MD5加密技术，参照步骤12中生成的加密字的内容对字符串G进行加密，得到校验密码；
步骤20，认证服务器比较校验密码和验证密码是否相同，如相同，则执行步骤21；否则，则向交换机返回认证失败，并终止流程；
步骤21，向交换机返回认证成功的信息；
步骤22，交换机向客户端返回认证成功的消息。
最后，本申请所提供的方法，主要是针对防止第三方恶意侵入、恶意登陆的情况。具体而言，主要防止非法的第三方的802.1x客户端的接入的问题。其中，第三方802.1x客户端指的是从任意的网络资源点上下载的通用的802.1x认证客户端(客户端中没有防第三方标记)，以及，其他厂家基于802.1x协议所设计的客户端(不同厂家的客户端类型不同，因而对应的防第三方标记不同，进而不同厂家的客户端不能共用)，可以防止其他厂家802.1x客户端的非法接入(只要客户端类型不同，就无法共用)。
与前述方法相同的，本申请还提供了一种以用户端为主体的基于802.1X协议的认证方法，该方法包括：
向接入设备发起认证请求；
在接收到接入设备所返回的询问通知后，通过接入设备向认证服务器发送第一应答消息，以使认证服务器对验证用户名进行第一验证；第一应答消息中携带有验证用户名；
在接收到加密字后，客户端通过接入设备向认证服务器发送第二应答消息，以使认证服务器对验证密码进行第二验证，以确定客户端是否通过认证；第二应答消息中携带有验证密码；验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，和/或，验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端所对应的防第三方标记不同；加密字是认证服务器对验证用户名进行第一验证，且第一验证通过后，由认证服务器随机生成的。
与前文中所提供的方法相对应的，本申请还提供了基于802.1X协议的认证系统，该系统包括：依次顺序通讯连接的客户端、接入设备和认证服务器；
客户端，用于向接入设备发起认证请求；并通过接入设备向认证服务器发送第一应答消息，第一应答消息中携带有验证用户名；以及，通过接入设备向认证服务器发送第二应答消息，第二应答消息中携带有验证密码；验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，和/或，验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端所对应的防第三方标记不同；
接入设备，用于向客户端发送询问通知；和转发第一应答消息，以及转发第二应答消息；
认证服务器，用于对验证用户名进行第一验证；若第一验证通过，则认证服务器通过接入设备向客户端发送随机生成的加密字；以及，对验证密码进行第二验证，以确定客户端是否通过认证。
为了避免内容重复，以用户端为主体的基于802.1X协议的认证方法和基于802.1X协议的认证系统的具体内容均可以参照前述的基于802.1X协议的认证方法。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (14)

1.基于802.1X协议的认证方法，其特征在于，包括：
客户端通过接入设备向认证服务器发送第一应答消息，所述第一应答消息中携带有验证用户名；
认证服务器对验证用户名进行第一验证；
若第一验证通过，则认证服务器通过接入设备向客户端发送随机生成的加密字；
客户端通过接入设备向认证服务器发送第二应答消息，所述第二应答消息中携带有验证密码；所述验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，所述验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端中所存储的所述防第三方标记不同；
认证服务器对所述验证密码进行第二验证，以确定所述客户端是否通过认证；
所述方法还包括：客户端向第三方平台发起下载请求，所述下载请求中携带有验证信息，所述验证信息包括以下的一种或多种，类别信息、地域信息、时间信息；
第三方平台将与所述下载请求中的验证信息相对应的防第三方标记向客户端发送。
2.根据权利要求1所述的基于802.1X协议的认证方法，其特征在于，步骤认证服务器对第一应答消息进行第一验证包括：
认证服务器提取所述第一应答消息中的防第三方标记；
认证服务器验证所述防第三方标记是否为真，若是，则所述第一验证通过。
3.根据权利要求1所述的基于802.1X协议的认证方法，其特征在于，所述验证用户名中至少携带有防第三方标记、实际用户名和实际密码；
步骤认证服务器对验证用户名进行第一验证包括：
认证服务器分别防第三方标记、实际用户名和实际密码进行验证，若防第三方标记、实际用户名和实际密码均为真，则所述第一验证通过。
4.根据权利要求3所述的基于802.1X协议的认证方法，其特征在于，携带在所述验证用户名中的所述防第三方标记、实际用户名和实际密码均是分别独立的进行过加密的，且客户端至少使用了两种不同的加密算法分别对防第三方标记、实际用户名和实际密码中的至少两个进行了加密；
步骤认证服务器对验证用户名进行第一验证还包括：
认证服务器对加密后的防第三方标记、实际用户名和实际密码进行解密。
5.根据权利要求3所述的基于802.1X协议的认证方法，其特征在于，防第三方标记、实际用户名和实际密码是按照预设的排列格式，排列在验证用户名中的；所述排列格式包括：排列次序，和/或间隔符的设置位置，和/或间隔符的表达形式；
步骤认证服务器对验证用户名进行第一验证还包括：
认证服务器对所述验证用户名中防第三方标记、实际用户名和实际密码的排列格式进行验证，若验证通过，则执行步骤认证服务器分别防第三方标记、实际用户名和实际密码进行验证。
6.根据权利要求4所述的基于802.1X协议的认证方法，其特征在于，还包括：
客户端分别使用预先存储在本地的第一加密算法和预设的非对称加密算法对对用户输入的实际密码进行加密，得到验证密码；使用所述非对称算法进行加密时，使用所述加密字。
7.根据权利要求6所述的基于802.1X协议的认证方法，其特征在于，步骤认证服务器对所述验证密码进行第二验证包括：
认证服务器分别使用预先存储在本地的第二加密算法和预设的非对称加密算法对预先存储在本地的实际密码进行加密，得到参考密码；使用所述非对称算法进行加密时，使用所述加密字；
认证服务器比较参考密码和验证密码是否相同，若相同，则所述客户端通过认证。
8.根据权利要求7所述的基于802.1X协议的认证方法，其特征在于，对所述验证用户名中的防第三方标记、实际用户名和实际密码进行加密所使用的加密算法和对验证密码中的实际密码进行加密所使用的加密算法不同。
9.根据权利要求1所述的基于802.1X协议的认证方法，其特征在于，在步骤第三方平台将与所述下载请求中的验证信息相对应的防第三方标记向客户端发送前还包括：
第三方平台将与所述下载请求中的验证信息相对应的防第三方标记向认证服务器发送。
10.根据权利要求1所述的基于802.1X协议的认证方法，其特征在于，步骤第三方平台将与所述下载请求中的验证信息相对应的防第三方标记向客户端发送包括：
第三方平台将更新数据包向安装所述客户端的电子设备上发送，所述更新数据包中携带有防第三方标记和所述客户端的安装包。
11.根据权利要求1所述的基于802.1X协议的认证方法，其特征在于，还包括：
安全用户端将获取到的防第三方标记和对应的验证信息写入配置文件中；
安全用户端将所述配置文件上传至第三方平台。
12.根据权利要求1所述的基于802.1X协议的认证方法，其特征在于，还包括：
第三方平台在接收到调整指令后，对本地的防第三方标记进行更新；所述调整指令是第三方平台每隔预定时间生成的，或调整指令是由安全用户端所发出的，且所述调整指令中携带有用于形成更新后的防第三方标记的文件；
第三方平台将更新后的防第三方标记向目标客户端发送；所述目标客户端是第三方平台曾发送过所述更新之前的防第三方标记的客户端。
13.基于802.1X协议的认证方法，其特征在于，包括：
向接入设备发起认证请求；
在接收到接入设备所返回的询问通知后，通过接入设备向认证服务器发送第一应答消息，以使认证服务器对验证用户名进行第一验证；所述第一应答消息中携带有验证用户名；
在接收到加密字后，客户端通过接入设备向认证服务器发送第二应答消息，以使认证服务器对验证密码进行第二验证，以确定所述客户端是否通过认证；所述第二应答消息中携带有验证密码；所述验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，所述验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端所对应的所述防第三方标记不同；所述加密字是认证服务器对验证用户名进行第一验证，且第一验证通过后，由认证服务器随机生成的；
所述方法还包括：客户端向第三方平台发起下载请求，以使所述第三方平台将与所述下载请求中的验证信息相对应的防第三方标记向所述客户端发送；所述下载请求中携带有验证信息，所述验证信息包括以下的一种或多种，类别信息、地域信息、时间信息。
14.基于802.1X协议的认证系统，其特征在于，包括：依次顺序通讯连接的客户端、接入设备和认证服务器；
客户端，用于向接入设备发起认证请求；并通过接入设备向认证服务器发送第一应答消息，所述第一应答消息中携带有验证用户名；以及，通过接入设备向认证服务器发送第二应答消息，所述第二应答消息中携带有验证密码；所述验证密码是客户端根据存储在客户端中的防第三方标记、用户输入的实际密码和加密字生成的，所述验证用户名是客户端根据用户输入的实际用户名和存储在客户端中的防第三方标记生成的；不同类型的客户端所对应的所述防第三方标记不同；
接入设备，用于向客户端发送询问通知；和转发第一应答消息，以及转发第二应答消息；
认证服务器，用于对验证用户名进行第一验证；若第一验证通过，则认证服务器通过接入设备向客户端发送随机生成的加密字；以及，对所述验证密码进行第二验证，以确定所述客户端是否通过认证；
所述客户端，还用于向第三方平台发起下载请求，以使所述第三方平台将与所述下载请求中的验证信息相对应的防第三方标记向所述客户端发送；所述下载请求中携带有验证信息，所述验证信息包括以下的一种或多种，类别信息、地域信息、时间信息。
CN201710295109.6A 2017-04-28 2017-04-28 基于802.1x协议的认证方法及系统 Active CN106954216B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710295109.6A CN106954216B (zh) 2017-04-28 2017-04-28 基于802.1x协议的认证方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710295109.6A CN106954216B (zh) 2017-04-28 2017-04-28 基于802.1x协议的认证方法及系统

Publications (2)

Publication Number Publication Date
CN106954216A CN106954216A (zh) 2017-07-14
CN106954216B true CN106954216B (zh) 2020-07-14

Family

ID=59477941

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710295109.6A Active CN106954216B (zh) 2017-04-28 2017-04-28 基于802.1x协议的认证方法及系统

Country Status (1)

Country Link
CN (1) CN106954216B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107733852B (zh) * 2017-08-24 2019-06-21 北京三快在线科技有限公司 一种身份验证方法及装置，电子设备
CN108769058B (zh) * 2018-06-20 2021-02-05 新华三技术有限公司 一种接入认证方法及装置
CN109088855A (zh) * 2018-07-12 2018-12-25 新华三信息安全技术有限公司 一种身份认证的方法及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006013150A1 (en) * 2004-08-02 2006-02-09 Service Factory Sf Ab Sim-based authentication
CN101977383A (zh) * 2010-08-03 2011-02-16 北京星网锐捷网络技术有限公司 网络接入的认证处理方法、系统、客户端和服务器
CN104901940A (zh) * 2015-01-13 2015-09-09 易兴旺 一种基于cpk标识认证的802.1x网络接入方法
CN105119940A (zh) * 2015-09-16 2015-12-02 北京博维亚讯技术有限公司 基于本地认证802.1x认证系统认证方法及认证设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7810138B2 (en) * 2005-01-26 2010-10-05 Mcafee, Inc. Enabling dynamic authentication with different protocols on the same port for a switch
CN101296086B (zh) * 2008-06-18 2010-12-08 成都市华为赛门铁克科技有限公司 接入认证的方法、系统和设备
CN101711022A (zh) * 2009-11-18 2010-05-19 卓望数码技术（深圳）有限公司 一种wlan接入终端、认证服务器和认证方法
CN102790674B (zh) * 2011-05-20 2016-03-16 阿里巴巴集团控股有限公司 身份验证方法、设备和系统
CN103581906A (zh) * 2012-08-02 2014-02-12 中兴通讯股份有限公司 一种通过wlan网络进行入口认证的方法和数据终端
CN103716334A (zh) * 2014-01-13 2014-04-09 深圳市共进电子股份有限公司 基于802.1x协议的认证方法及系统
CN106341233A (zh) * 2015-07-08 2017-01-18 阿里巴巴集团控股有限公司 客户端登录服务器端的鉴权方法、装置、系统及电子设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006013150A1 (en) * 2004-08-02 2006-02-09 Service Factory Sf Ab Sim-based authentication
CN101977383A (zh) * 2010-08-03 2011-02-16 北京星网锐捷网络技术有限公司 网络接入的认证处理方法、系统、客户端和服务器
CN104901940A (zh) * 2015-01-13 2015-09-09 易兴旺 一种基于cpk标识认证的802.1x网络接入方法
CN105119940A (zh) * 2015-09-16 2015-12-02 北京博维亚讯技术有限公司 基于本地认证802.1x认证系统认证方法及认证设备

Also Published As

Publication number Publication date
CN106954216A (zh) 2017-07-14

Similar Documents

Publication Publication Date Title
US11870758B2 (en) Systems and methods for application identification
JP6625211B2 (ja) 部分的に信頼できる第三者機関を通しての鍵交換
US11336641B2 (en) Security enhanced technique of authentication protocol based on trusted execution environment
US7673334B2 (en) Communication system and security assurance device
KR101269698B1 (ko) 트러스티드 프로세싱 기술을 사용하는 디지탈 권리 관리
US6732270B1 (en) Method to authenticate a network access server to an authentication server
US8301887B2 (en) Method and system for automated authentication of a device to a management node of a computer network
US20140245417A1 (en) Centralized secure management method of third-party application, system and corresponding communication system
EP4022473A1 (en) Decentralized data authentication
US20060265446A1 (en) Dynamic executable
US7757276B1 (en) Method for verifying configuration changes of network devices using digital signatures
CN104573516A (zh) 一种基于安全芯片的工控系统可信环境管控方法和平台
KR102177794B1 (ko) 사물인터넷 블록체인 환경에서의 디바이스 분산 인증 방법 및 이를 이용한 디바이스 분산 인증 시스템
JP5602165B2 (ja) ネットワーク通信を保護する方法および装置
CN106954216B (zh) 基于802.1x协议的认证方法及系统
CN109587134B (zh) 接口总线的安全认证的方法、装置、设备和介质
KR102116902B1 (ko) Https에서의 쿠키 무결성 검증 방법
KR102575471B1 (ko) 포털사이트 중계 서비스 제공 시스템 및 그 방법
TWI670990B (zh) 自動連線安全無線網路的方法與系統
CN117521052A (zh) 一种服务器隐私的保护认证方法、装置、计算机设备及介质
CN116545708A (zh) 单点登录系统及登录方法、装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20170714

Assignee: CHINA TECHNOLOGY EXCHANGE Co.,Ltd.

Assignor: BEIJING VRV SOFTWARE Corp.,Ltd.

Contract record no.: X2023110000147

Denomination of invention: Authentication Method and System Based on 802.1X Protocol

Granted publication date: 20200714

License type: Exclusive License

Record date: 20231201

EE01 Entry into force of recordation of patent licensing contract
PE01 Entry into force of the registration of the contract for pledge of patent right

Denomination of invention: Authentication Method and System Based on 802.1X Protocol

Effective date of registration: 20231206

Granted publication date: 20200714

Pledgee: CHINA TECHNOLOGY EXCHANGE Co.,Ltd.

Pledgor: BEIJING VRV SOFTWARE Corp.,Ltd.

Registration number: Y2023110000520

PE01 Entry into force of the registration of the contract for pledge of patent right