赞
踩
最近在做一个项目时候要用到摄像头人脸抓拍,人脸识别等功能,原本使用海康的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 :https://github.com/kyhkl/hivisoion_projcet.git
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。