关于海康摄像头的摘要认证(转载）_海康isapi登录

转载自：关于海康摄像头的摘要认证_y673533511的博客-CSDN博客

关于海康
摄像头的摘要认证

y673533511 2019-03-11 10:30:01

4132  正在上传…重新上传取消​ 收藏 6 

版权

最近在做一个项目时候要用到摄像头人脸抓拍，人脸识别等功能，原本使用海康的SDK就可以解决的，但是我们项目是在arm平台下开发的，而海康的SDK不支持arm平台，无奈联系的海康的技术支持，他们提供的了一种基于海康私有ISAPI 协议，通过HTTP进行摘要认证。

什么是摘要认证？ 简单的说就是你要登录某个网站，网站会让你输入用户名密码才才能进行正常的操作，这首先浏览器会首先发出一个请求，然后服务器传回一个认证信息 ，该认证信息包含有认证域，随机密码，header等信息。当你输入正确的账户和密码，浏览器会自动根据你的账户和密码生成摘要认证信息，然后发送给服务器，服务器提取摘要信息，选择验证算法，对账户和密码进行验证，验证通过返回200  ok  ，然后就可正常的浏览网页了。类似于路由器的登录界面。具体的摘要认证流程学习，大家自行百度学习。

关于海康摘要认证方法的介绍参考官方文档如下：

1 摘要认证介绍 
ISAPI 协议基于 HTTP REST 架构，协议交互需要安全认证，Digest 摘要认证比 Basic 基础认证的安全级别
更高： 
1）通过传递用户名、密码等计算出来的摘要来解决明文方式在网络上发送密码的问题。 
2）通过服务产生随机数 nonce 的方式可以防止恶意用户捕获并重放认证的握手过程。 
1.1 认证握手过程 
1. 客户端发出一个没有认证证书的请求。 
GET /ISAPI/Security/userCheck HTTP/1.1 
Accept: text/html, application/xhtml+xml, */* 
Accept-Language: zh-CN 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Accept-Encoding: gzip, deflate 
Host: 10.18.37.12 
Connection: Keep-Alive 
注：此处示例为用户名密码校验的ISAPI协议命令（GET方法），每次下发新的命令都需要重新认证。 
 
 
 
2. 服务器产生一个随机数nonce，并且将该随机数放在WWW-Authenticate响应头，与服务器支持的认
证算法列表，认证的域realm一起发送给客户端。 
HTTP/1.1 401 Unauthorized 
Date: Wed, 30 May 2018 19:16:52 GMT 
Server: App-webs/ 
Content-Length: 178 
Content-Type: text/html 
Connection: keep-alive 
Keep-Alive: timeout=10, max=99 
WWW-Authenticate: Digest qop="auth", realm="IP Camera(12345)", 
nonce="4e5749344e7a4d794e544936596a4933596a51784e44553d", stale="FALSE" 
注：401 Unauthorized表示认证失败、未授权。返回的WWW-Authenticate表示设备支持的认证方式，此
处设备只支持Digest摘要认证方式。 
 
 
 
HTTP/1.1 401 Unauthorized 
Date: Wed, 30 May 2018 19:23:32 GMT 
Server: App-webs/ 
Content-Length: 178 
Content-Type: text/html 
 
 
Connection: keep-alive 
Keep-Alive: timeout=10, max=99 
WWW-Authenticate: Digest qop="auth", realm="IP Camera(12345)", 
nonce="4f5455784e4452684f544136596a49344d54566a4f57553d", stale="FALSE" 
WWW-Authenticate: Basic realm="IP Camera(12345)" 
注：401 Unauthorized表示认证失败、未授权。返回的WWW-Authenticate表示设备支持的认证方式，此
处设备同时支持Digest摘要认证和Basic认证两种方式。stale表示nonce值是否过期，如果过期会生成新的随
机数。 
 
 
 
3. 客户端接收到401响应表示需要进行认证，选择一个算法（目前只支持MD5）生成一个消息摘要
（message digest，该摘要包含用户名、密码、给定的nonce值、HTTP方法以及所请求的URL），将摘要放到
Authorization的请求头中重新发送命令给服务器。如果客户端要对服务器也进行认证，可以同时发送客户端
随机数cnonce，客户端是否需要认证，通过报文里面的qop值进行判断，详见1.2章节介绍。 
GET /ISAPI/Security/userCheck HTTP/1.1 
Accept: text/html, application/xhtml+xml, */* 
Accept-Language: zh-CN 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Accept-Encoding: gzip, deflate 
Host: 10.18.37.12 
Connection: Keep-Alive 
Authorization: Digest username="admin",realm="IP 
Camera(12345)",nonce="595463314d5755354d7a4936596a49344f475a6a5a44453d",uri="/ISAPI/Security/userCheck",cnonc
e="011e08f6c9d5b3e13acfa810ede73ecc",nc=00000001,response="82091ef5aaf9b54118b4887f8720ae06",qop="auth" 
 
 
 
4. 服务接收到摘要，选择算法以及掌握的数据，重新计算新的摘要跟客户端传输的摘要进行比较，验
证是否匹配，若客户端反过来用客户端随机数对服务器进行质询，就会创建客户端摘要，服务可以预先
将下一个随机数计算出来，提前传递给客户端，通过 Authentication-Info 发送下一个随机数。该步骤选
择实现。 
HTTP/1.1 200 OK 
Date: Wed, 30 May 2018 19:32:49 GMT 
Server: App-webs/ 
Content-Length: 132 
Connection: keep-alive 
Keep-Alive: timeout=10, max=98 
Content-Type: text/xml 
 
 
 
<?xml version="1.0" encoding="UTF-8"?> 
<userCheck> 
<statusValue>200</statusValue> 
<statusString>OK</statusString> 
</userCheck> 
注：响应200 OK表示认证成功。 
 
 
 
详细说明请参考RFC 2617规范文档。 
 
 
1.2 摘要计算过程 
在说明如何计算摘要之前，先说明参加摘要计算的信息块。信息块主要有两种： 
1. 表示与安全相关的数据的A1 
A1中的数据时密码和受保护信息的产物，它包括用户名、密码、保护域和随机数等内容，A1只涉及安
全信息，与底层报文自身无关。 
若算法是：MD5 
则 A1=<user>:<realm>:<password> 
若算法是：MD5-sess 
则 A1=MD5(<user>:<realm>:<password>):<nonce>:<cnonce> 
 
 
 
2. 表示与报文相关的数据的A2 
A2表示是与报文自身相关的信息，比如URL，请求反复和报文实体的主体部分，A2加入摘要计算主要目
的是有助于防止反复，资源或者报文被篡改。 
若 qop 未定义或者 auth： 
A2=<request-method>:<uri-directive-value> 
若 qop 为 auth:-int 
A2=<request-method>:<uri-directive-value>:MD5(<request-entity-body>) 
注：<uri-directive-value>为完整的协议命令 URI，比如“/ISAPI/Security/userCheck”。 
 
 
 
下面定义摘要的计算规则： 
若 qop 没有定义： 
摘要 response=MD5(MD5(A1):<nonce>:MD5(A2)) 
 
 
 
若 qop 为 auth: 
摘要 response=MD5(MD5(A1):<nonce>:<nc>:<cnonce>:<qop>:MD5(A2)) 
 
若 qop 为 auth-int: 
摘要 response= MD5(MD5(A1):<nonce>:<nc>:<cnonce>:<qop>:MD5(A2)) 
1.3 随机数的生成 
RFC2617建议采用这个假想的随机数公式： 
nonce = BASE64(time-stamp MD5(time-stamp ":" ETag ":" private-key)) 
其中: 
time-stamp是服务器产生的时间戳或者其他不会重复的序列号，ETag是与所请求实体有关的HTTP ETag
首部的值，priviate-key是只有服务器知道的数据。 
 
 
 
这样，服务器就可以收到客户端的认证首部之后重新计算散列部分，如果结果与那个首部的随机数不
符，或者是时间戳的值不够新，就可以拒绝请求，服务器可以通过这种方式来限制随机数的有效持续时间。 
 
 
 
包括了ETag可以防止对已经更新资源版本的重放请求。注意：在随机数中包含客户端IP，服务器好像就
可以限制原来获取此随机数的客户端重用这个随机数了，但这会破坏代理集群的工作，使用代理集群时候，
来自单个用户的多条请求通常会经过不同的代理进行传输，而且IP地址欺骗实现起来也不复杂。 
 
 
 
对于我司设备，认证的随机数超时时间如下所示： 
认证返回的 nonce 是 3s 超时； 
非认证返回的 none 是 30s 超时。 

主要流程如下

客户端是arm板  采用socket 编程，服务端是海康摄像头。 采用短连接方式。

1.客户端发送一个没有认证的请求

GET /ISAPI/Streaming/channels/101/picture HTTP/1.1
Host: 192.168.3.64
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

2.服务端发送返回如下

HTTP/1.1 401 Unauthorized
Date: Mon, 11 Mar 2019 10:22:35 GMT
Server: App-webs/
Content-Length: 178
Content-Type: text/html
Connection: close
WWW-Authenticate: Digest qop="auth", realm="DS-2CD2520F", nonce="4d6a553452444d30525441364e6d4d304e6a68684e47553d", stale="FALSE"
WWW-Authenticate: Basic realm="DS-2CD2520F"
 
<!DOCTYPE html>
<html><head><title>Document Error: Unauthorized</title></head>
<body><h2>Access Error: 401 -- Unauthorized</h2>
<p>Authentication Error</p>
</body>
</html>

3.客户端根据服务端返回的认证域 nonce 等信息，加入用户名和密码，生成response校验 ，重新发回给服务器  如下

GET /ISAPI/Streaming/channels/101/picture HTTP/1.1
Host: 192.168.3.64
Connection: keep-alive
Authorization: Digest username="admin", realm="DS-2CD2520F", nonce="4d6a553452444d30525441364e6d4d304e6a68684e47553d", uri="/ISAPI/Streaming/channels/101/picture", response="3993a815e5cdaf4470e9b4f9bd41cf4a", qop=auth, nc=00000001, cnonce="93d4d37df32e1a85"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 SE 2.X MetaSr 1.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

4.服务端验证通过返回200 ok

HTTP/1.1 200 OK
Content-Type: image/jpeg; charset="UTF-8"
Content-Length:153686
 

5.接着返回图片数据

这就是一次杭康摄像头摘要认证的过程，该源码就是抓取摄像头的一张图片。

程序源码请移步github ：GitHub - kyhkl/hivisoion_projcet