基于标识的动态口令系统

2017-02-06 23:54刘莹龙毅宏
软件 2016年6期
关键词:身份认证

刘莹+龙毅宏

摘要:作为用户身份验证技术,动态口令技术比传统的静态口令技术具有更高的安全性。针对目前动态口令系统存在的用户令牌种子密钥管理麻烦、种子密钥数据库安全要求高,与应用系统集成存在帐户方面的限制,缺少用户种子密钥自动更新的功能等问题,提出了一种基于标识的动态口令系统方案,并从基于时间与基于挑战/响应两种方式进行实现。该系统具有用户种子密钥自动更新的功能,并且具有易于密钥管理、易于与应用系统集成等特点。

关键词:身份认证;动态口令;身份标识。

引言

口令是目前用的最广泛的身份认证技术。口令分为静态与动态两种,传统的静态口令身份认证技术采用简单的用户名和固定不变的口令进行登录验证,存在易于被网络窃听、易受字典攻击等问题。1981年,Lamport提出了一次性口令的概念,引入了不确定因素,保证用户每次使用不同的口令进行登录,因此具有更高的安全性。Haller在Lamport基础上提出S/KEY方案,该方案基于MD4和MD5算法,采用c/s模式的操作,能够对用户与服务器进行综合验证。但是该方案生成的动态口令有限,用完之后得重新注册才能使用。

常用的动态口令的实现方式有基于时间的动态口令生成方式和基于挑战/响应的动态口令生成方式。其中基于时间的动态口令生成方式属于同步认证技术,引人时间作为不确定因素参与动态口令的生成,基于挑战/响应的动态口令生成方式属于非同步认证技术,引人一个随机产生的挑战数作为不确定因素参与动态口令的生成。这两种动态口令生成方式都采用单向散列函数生成口令,它们的安全性由单向散列函数的不可逆性保证,常用的单向散列函数包括:SHA-1、SHA-2(SHA-224、SHA-256、SHA-384、SHA-512)、MD5等。

目前的动态口令系统存在以下几个方面的问题:

1)用户动态口令种子密钥管理麻烦、密钥集中存储安全要求高。

动态口令系统服务端需要分别为每位用户创建一个账户以维护和管理种子密钥,种子密钥集中存储需要极高的安全性。

2)与应用系统集成存在帐户方面限制。

当采用动态口令系统的应用系统对用户提交的动态口令进验证时,应用系统需要知道用户在动态口令系统的帐户名,一般采取让用户在应用系统与动态口令系统中使用相同的帐户名,或是将用户在应用系统中的帐户同用户在动态口令系统中的帐户绑定的方法,但前者对应用系统造成限制,不适用于已存在的应用系统,后者实现账户绑定比较麻烦。

3)缺少用户种子密钥自动更新的功能。

1基于标识的动态口令系统整体设计

本文中使用到的符号及含义如表1所示:

1.1系统结构

基于标识的动态口令系统结构如图1所示,主要包括:

1)Cotv:安装在用户手机端或是用户主机中的一个独立程序,维护一个本地存储的终端种子密钥keye,由用户控制完成由不确定因素(时间或挑战数)计算动态口令的过程,自主定时与Soto通信,更新keyc。

2)Sotp:维护有一张保存UID、serial以及key。的标识信息表。Soto主要完成对otp的验证及响应Coto更新key。的请求的功能。

3)web页面:完成用户与Sweb之间交互。接收用户输入信息,反馈提示信息。

4)Sweb:维护有一个保存username和对应用户UID的数据表。主要完成用户web界面的通讯、用户存在性验证(对于挑战数生成动态口令的方案而言还包括产生随机码功能模块)以及传递待验证动态口令信息等工作。

1.2验证过程

整个用户身份验证基本过程如下:

1)用户将username通过web页面传送给Sweb。

2)sweh验证username存在性,若存在则提示用户输入otp,对于基于挑战/响应方案,Sweb同时返回一串随机数。

3)对于基于挑战/响应的方案,用户通过操作Coto,利用返回的随机数生成该用户当前的otp;对于基于时间的方案,Coto利用当前时间生成用户当前的otp。

4)用户将otp输入web页面后,Sweb根据username查询对应的用户UID并打包相关数据打包发送给Soto。对于基于时间的方案,打包数据包括UID和待验证otp;对于基于挑战/响应的方案,打包数据包括UID、待验证otp以及参与计算的随机数。

5)Sotp通过计算,验证接收到otp的正确性,并经由sweb曲向用户返回验证结果。

6)Coto每隔一段时间(如14天)自发地与Sotp进行通信,更新用户的keyc。

2系统主要功能的实施

2.1基于标识的动态口令的生成

Sotp为每一位用户保存一个初始值为0的serial。记此处符号“+”表示字符串连接,Hk()表示KeyedHash计算。

UID+serial UIDEX

(1)

Hk(UIDEX,keys)=key。

(2)

Hk(不确定因子,keyc)=otp

(3)

如式(1)所示,将某一用户UID和其对应的serial值进行字符串连接即产生该用户的UIDEX。Sow利用用户UIDEX和key通过如(2)式KeyedHash运算得出该用户的keye key。由各用户的Cow保存管理。keyc和不确定因素(时间/挑战数)通过(3)式获得该用户当前状态下的otp。

2.2动态口令验证过程

Sow接收到动态口令验证请求后,遵循如图2所示过程进行验证:

1)利用传入的数据,查询标识信息表以确认对应UID存在性,若存在则继续后续操作,否则验证未通过。

2)由用户UID查询标识信息表以获取对应的serial值,并利用keys,根据(1)(2)式生成该用户的key。

3)对于基于挑战/响应的方案,Sow利用验证请求数据中的随机数和上一步获取的keyc根据(3)式得到动态口令标准值otpl;对于基于时间的方案,Sow获取精确到秒的本地时间T,由T截取到分钟后的数据t与keyc根据(3)式得到动态口令标准值otp]。

4)比较otpl和待验证otp,若相同则验证通过,若不同,对于基于挑战/响应的方案而言则验证未通过;对于基于时间的方案,还需进行后续调整操作。

5)对于基于时间的方案,考虑可能存在的时间不同步问题,以一分钟作为一个动态口令生成与验证时间段,Sotp计算T。距离该时刻所在的动态口令生成与验证时间段的起始与结束两个时间点的时间长度,判断最小的时间长度是否在临界偏差范围(如1s)内。若在,则以距离更近的相邻的生成与验证时间段截取到分钟后的时间数据作为备选时间数据ts计算动态口令备选标准值otp2,若超出临界偏差范围则验证未通过。

6)比较otp2和otp,若相同则验证通过,若不同则验证未通过。

2.3定时更新

Cotp内设置定时器,设定每隔一段时间(如14天)触发一次的更新。

Cotp通过动态口令向Soto证明当前拥有有效的key~。Sow验证、确认有效后,Sow对用户serial值进行加1操作,并用更新后的serial值生成新的终端种子密钥。

若keyc自动更新失败,用户可通过手工方式更新。

2.4时间同步

对于基于时间的方案,可使用NTP协议实现Cow与Sow的时钟同步,基本过程如下:

Cotp获取本地时间t1后向Sotp发送一条时间调整命令,Sow接收后获取本地时间t2。

2)Sow获取本地时间t3后向Cow返回一条时间调整响应,Cow接收后获取本地时间t4。

3)Coto根据(4)(5)式分别计算单程网络延迟6和时间偏差d:

6=((t4-t1)-(t3-t2))/2

(4)

d=((t2-t1)+(13-t4))/2

(5)

Coro获取本地时间t,由(6)式计算调整后的时间T:

T-t+d+6

(6)

Cotp首次安装时进行时间同步,此后若出现时间同步异常,用户可通过手工方式同步。

2结束语

本文针对当前动态口令技术存在的问题,提出了一种基于标识的动态口令系统方案,并从基于时间与基于挑战/响应两种方式对该方案进行了描述。提出的方案具有以下优势:

1)无对集中保存的用户种子密钥进行安全保护的要求。

动态口令系统服务端不需要单独为每一个用户保存、维护终端种子密钥,而是在需要终端种子密钥的时候利用用户身份标识和系统种子密钥通过散列计算得到,从而省去了集中保存和管理用户终端种子密钥的需要和安全保护要求。

2)易于与应用系统集成

在与应用系统集成时,将应用系统原有的帐户口令改为存放用户的身份标识即可,应用系统既可以使用原有的帐户管理系统,也可使用统一的帐户管理系统,没有特别的要求限制。

3)具有自动更新用户种子密钥的功能

本方案中动态口令生成器定时触发终端种子密钥更新,主动与动态口令服务器进行通信,实现用户种子密钥的自动更新。

猜你喜欢
身份认证
云电子身份管理与认证系统中的关键技术优化改进