技术说明：用于安全网络身份验证的区块链技术和二维码

我们越来越多地在许多应用程序中看到二维码，这在一定程度上要归功于与区块链技术相关的众多项目。 二维码以前被视为中国和其他亚洲国家的特有现象（如微信的二维码），但现在，二维码（QR码）被广泛用于身份验证、支付、信息交换等。

使用 QR 将基本的少量信息传输到移动设备可能很简单（必须包括库和少量代码）。 然而，在安全方面，基于二维码构建一个方便、安全的解决方案变得非常困难。 同样在大多数情况下，您需要一个替代解决方案，例如在没有第二个屏幕的情况下执行身份验证。 最近了解到的一些网银登录移动设备支持身份存储在以太坊区块链上的项目，详细分享一下：

环境

对于移动开发，我们使用 C# 和 Xamarin 表单，网上银行原型是用 Ruby-on-rails 编写的。 移动应用程序用于在以太坊区块链上创建和管理身份。 该应用程序拥有以太坊密钥，它是所有身份属性（姓名、国籍等）和其他证明（例如大学的大学学位）的核心。

什么是目标任务

通常身份验证是在外部仲裁员的帮助下完成的，将数据直接发送给消费者或提供验证，例如用于登录 Google Works 的 OpenID Connect。 在我们的方案中，这一切都是通过区块链架构提供的非对称加密和签名能力来完成的。

在这种情况下，区块链作为参与者充当安全存储空间（从某种意义上说，在那里发布的信息无法更改）。 公共实体可以在那里发布他们的详细信息，例如在线银行提供他们的名字以方便用户。 这只能由地址密钥的持有者完成，并与网站的 SSL 证书相结合以太坊私钥是多少位，为用户提供了强大的安全性和检查身份信息接收者真实性的简便方法。

对于用户来说，工作流程是不同的，因为个人信息不能公开，所以只有证明部分被发布到区块链上，信息是由一些外部验证者（比如我们的银行）提供的。

对于用户而言，这允许使用不同 ID 消费者（例如银行和在线商家）简单地重用现有身份，而无需依赖单一的中央控制实体。 企业还可以受益于该模型的轻松集成，以及通过获得验证与其他实体建立信任。

认证流程

认证过程如下：

用户使用 ID Consumer 网站上的移动应用程序扫描二维码。 二维码包含身份主体信息、获取身份主体公钥位置的URL、安全和属性要求。

移动应用程序加载身份主体的公钥、安全密钥和URL 以发布身份数据。

该移动应用程序请求用户批准与以太坊地址识别的 ID 消费者共享身份详细信息。 底层区块链协议提供对该地址的验证，用户可以确定身份数据接收方的可信度。

身份数据由用户的以太坊密钥签名，并使用身份消费者公钥的非对称加密进行加密。

加密后的有效信息连同安全密钥一起发送给身份消费者。

ID 消费者使用安全密钥来解密私钥，该私钥是加密的并且特定于该登录会话。

恢复私钥后，消费者使用它来解密有效消息。

解密有效载荷中的签名用于恢复签名者的以太坊公钥和地址。 如果地址与有效消息中的地址匹配，我们可以假设登录成功。

QR码由以下代码生成。 我们正在为登录会话建立唯一标识符并指定身份信息的接收者。 由于 QR 码的生命周期很短，我们还必须包含一个时间戳，以便移动应用程序可以在请求过期时显示倒数计时器。

def qr_code( root_url )
 params = {
 by: "0x5ddA491Bc5Fc1C7dC5A3B90078eA24d3b1407482",
 id: self.uuid,
 at: Time.now.to_i,
 eu: crypto_url(root_url),
 en: true,
 v: 1,
 }.to_query

 qr_string = "kycex://auth/request?#{params}"
 puts "INFO: QR is: #{qr_string}"
 puts "INFO: crypto URL is: #{crypto_url(root_url)}"
 qr_string
end

URI 模式 kycex 是指移动应用程序注册的模式，能够处理来自任何二维码阅读器应用程序的身份验证请求。 然后，移动应用程序使用 eu（加密 URL）参数检索用于有效负载加密的公钥。

def generate_key
 nonce = SecureRandom.uuid
 rsa_key = OpenSSL::PKey::RSA.new(2048)
 if rsa_key == nil
 puts "ERROR: could not generate session encryption key!"
 return
 end
 cipher = OpenSSL::Cipher::Cipher.new('des3')
 if cipher == nil

 puts "ERROR: could not encrypt key!"
 return
 end
 self.privkey = rsa_key.to_pem(cipher, nonce)
 self.pubkey = Base64.encode64(rsa_key.public_key.to_pem)
 self.nonce = nonce
end

加密 URL 会生成一个新的 RSA 公钥/私钥对。 私钥使用 3DES 对称加密进行加密并存储在本地。 公钥返回到移动设备并在本地丢弃。 这可确保如果本地存储遭到破坏，则无法以明文形式读取私钥，并且在到达 ID 消费者之前无法访问加密的有效负载。 为每次身份验证使用新的 RSA 密钥对也提高了安全性，因为重复使用相同的密钥对会导致安全风险以太坊私钥是多少位，例如破坏一个会话影响其他人。我们在下面的签名过程中也使用不同的密钥，因为重复使用相同的密钥用于签名和加密操作肯定会降低整体安全性 C#中的RSA加密部分使用BouncyCastle nuget包完成

可以使用 RSA 加密进行加密的数量由选定的密钥长度定义。 在我们的例子中，这是 2048 位，最大输入块大小为 245 字节。 当使用 PKCS1 OAEP 编码时，每个块转换为 256 字节，因为编码添加了控制结构并由于增加了熵而使密码更加健壮，从而提高了整体安全性。 如果明文块小于 245 字节，则通过编码将其填充到正确的所需长度。 这就是密文长度总是 n × 256 字节的原因。 在Ruby的解密端，可以使用相同的步骤（倒序）

# Check if this session has stored encrypted private key
if self.privkey.nil? || self.privkey.empty?
 raise "Session request in invalid state"
end
# We need a decryption key for our private key
if nonce.nil? || nonce.empty?

 raise "Session request in invalid state"
end
# Use builtin OpenSSL API binding to initialize encrypted key
rsa_key = OpenSSL::PKey::RSA.new(self.privkey, nonce)
if rsa_key.nil?
 raise "Session key decryption failed"
end
# HTTP POST contains base64 encoded payload
# p now contains binary cyphertext
p = Base64.urlsafe_decode64(payload)
# As we know the key length and corresponding block size we set this manually
bs = 256
i = 0
json = ""
while (i < p.length)

 begin
 # Decrypt each block individually using the correct encoding and padding
 json << rsa_key.private_decrypt(p[i,bs], OpenSSL::PKey::RSA::PKCS1_OAEP_PADDING)
 i += bs
 rescue OpenSSL::PKey::RSAError
 raise "Session payload decryption failed"
 end
end
if json.nil?
 raise "Session payload decryption failed"
end
# json should now contain a valid concatenated JSON structure
body = JSON.parse(json, :symbolize_names => true)

可以看出，区块链技术为以安全为中心的应用程序提供了良好的基础，因为安全方面已经内置到协议本身中。 另一方面，尽管区块链已经存在了一段时间，但令我惊讶的是，显然缺乏用于处理以太坊和比特币的椭圆曲线 (EC) secp256k1 密钥的好工具和库。 一个很好的例子是以太坊的签名验证：至少我找不到适合 Ruby 的应用程序，不得不使用比特币 gem，它基于比特币的 3 年历史的 libsecp256k1 实现。 另一个潜在的改进领域是用于小型有效负载的基于 EC 密钥的加密库。 虽然理论上没有 OpenSSL 的高级包装器，至少在 Ruby 中是这样。

另一方面，与具有共享令牌的传统系统相比，由区块链基础设施支持的单一数字身份可能是一个主要优势。 虽然目前整体采用率较低，而且每个人似乎都对玩加密市场更感兴趣，但我看到了借助区块链进行分布式透明身份验证和身份数据共享的巨大潜力。