第3部分: 从支付宝SDK的付款过程中了解公钥和私钥，加密和数字签名

目录

（请注意，数字签名实际上独立于哈希算法，AES对称加密和RSA非对称加密，或者数字签名是这三种方法的应用. ）

首先，我们必须了解公钥和私钥只是一个相对的概念. 也就是说，我们不能简单地将一对密钥中的一个称为公钥，而将另一个称为私钥. 为了人民. 生成一对密钥后，将专用密钥保存在生成​​器中，并由发布公共密钥. 您可以看到，当我们调用它们时，会将放在最前面，这可以帮助我们理解并避免混淆概念. 不能从其中一个派生公钥和私钥对.

可以暂时了解这种方式:

首次生成一对密钥时，没有公共密钥或私有密钥，但是将握住一个密钥并将其发布给他人使用. 正是这种“保留和释放”操作使这对密钥成为公共密钥和私有密钥，因此对于，他自己手中保存的密钥称为的私钥，而发布给其他人的密钥称为的公钥. 键. 该名称在此处带有，以表明一对密钥的公共和私有性质始终与它们的相关. （在实践中，私钥和公钥在生成时已经是公共和私有的，因为公钥和私钥是不同的生成机制，但是这种理解没有错，这有助于我们弄清背后的关系）<

例如:

当我们使用支付宝SDK时，我们的商家将生成一对密钥A和B，支付宝还将生成一对密钥C和D.

然后，如果我们的商人保存了A并将B释放给支付宝，则A被称为商人私钥，而B被称为商人公钥. （调用公钥和私钥时请注意的名称，以便我们能够理解并避免混淆）

当然，我们也可以保存B并将A发布到支付宝支付sdk，这样B称为商家专用密钥，而A称为商家公用密钥. （在实践中不会这样做，因为公钥和私钥是预先确定的，并且它们的生成机制是不同的，但是这种理解没有错，这有助于我们阐明其背后的关系）

类似地，假设支付宝保存了C并将D释放给我们，则C称为支付宝私钥，D称为支付宝公钥，反之亦然.

（1）什么是加密？

接下来，我们将了解加密的概念，首先了解支付宝的加密过程，然后介绍数字签名的概念.

当我们的商人和支付宝相互发布公钥时，我们有两个私钥: 商人私钥和支付宝公钥，而支付宝也有商人公钥和支付宝私钥. 键. 现在假设我们的商家想要将订单信息传输到支付宝，那么为了确保传输订单信息时数据的安全性（请注意，这种加密目的听起来很合理，但是实际上我们的商家方将订单信息传输到了支付宝以纯文本形式存在，但是有一个数字签名可以确保数据不会被篡改. 这将在后面提到. 现在让我们根据这个错误的目的向下看，这自然会导致以下反驳. 对于我们商人持有的密钥，我们可以采用两种加密方案:

这两种加密方案似乎都可以达到订单信息加密传输的效果，那么为什么我们看到支付宝开发平台让我们采用方案一而不是方案二？考虑一下，使用方案二，我们的商人甚至只需要存储支付宝的公钥. 我们不需要申请一对商人的公钥和私钥来维护. 支付宝不需要像我们保存的那么多商家. 公钥，不是更简单，那么为什么支付宝不让我们使用第二种解决方案？让我们在下面回答:

首先，支付宝开放平台说明: 当我们使用RSA（1024位密钥）进行加密时，支付宝分发给所有商家的支付宝公钥是相同的，也就是说，支付宝仅负责维护这么多商家. 支付宝公钥和私钥；当我们使用RSA2（2048位密钥）进行加密时，支付宝将为每个商家分配一个单独的支付宝公钥，也就是说，支付宝为每个商家维护一个单独的支付宝对. 公钥和私钥，当然，支付宝公钥一个商家下的多个应用程序是相同的. 很久以前就支持RSA，而最近才支持RSA2. 看到这篇文章

好吧，知道了上面的段落后，我们假设我们正在使用方案2（这样，我们的商人方可以省去在商人方应用商人的公钥和私钥的过程，而仅保留支付宝公共密钥），并使用RSA加密，业务逻辑如下:

方案2: 订单信息的加密传输和RSA加密

这是一个问题: notify_url很容易被盗. 一旦被盗，坏人就可以执行与商家相同的操作来发起付款请求，因为如果使用RSA加密，那么坏人还可以获取支付宝公钥，因此将始终向小明收费.

因此，支付宝需要确认付款请求确实是由商家而不是坏人发送给他们的，以避免坏人恶意地模仿商家发起付款请求并造成商家损坏. 如何实现这种验证效果？它使用数字签名，然后我们将通过方案一的实施过程来介绍数字签名的具体概念. 如果使用方案1，则需要将商人的私钥和支付宝公钥存储在我们的商人手中，而支付宝则需要存储商人的公钥和支付宝私钥. 方案1的业务流程如下:

解决方案1: 在订购信息中添加数字签名（称为签名）

这可以确保数据事务的安全性. 我们还可以看到，使用支付宝SDK来确保交易安全不是真正关于订单信息是否已加密和传输，而是如何确保商家和支付宝可以确认彼此的身份（形成数字）真实的签名. 加密的目的，而不是加密的传输，这里我们驳斥了上述目的），我们还可以看到:

（2）什么是数字签名？

说到这一点，让我们回想一下上面提到的RSA2加密. 支付宝将为每个商户分配一个单独的支付宝公钥，即，支付宝为所有商户维护一对独立的支付宝公钥和私钥. 数字签名也可以通过使用第二种方案来完成. 看来我们不需要我们的商人来申请商人的公钥和私钥. 但是，现在我们需要与以前的RSA加密兼容，因此第一种方案仍用于数字签名. 可以看出，数字签名不一定必须通过RSA加密生成. 可以使用MD5，SHA-1，AES和其他加密算法来生成数字签名，但是实际开发需要根据实际情况选择适当的加密算法来生成数字签名. 通常，我们会选择RSA加密来生成数字签名（例如，支付宝付款），或者选择MD5加密来生成数字签名（例如，微信支付）.

（3）加密和数字签名之间的联系和区别

从第一部分我们可以知道，为了确保商人和支付宝交易的安全性，公认的方法是在订单信息中添加数字签名以进行传输.

因此，支付宝还为我们提供了用于生成RSA密钥的一键工具，它可以帮助我们快速生成一对商人侧的公钥和私钥以及用于生成RSA密钥工具的一键下载地址

以下内容将对支付宝的付款流程进行一般性说明，并指出在实际开发中使用支付宝SDK时应注意的事项:

商家公共密钥:

支付宝私钥:

支付宝公钥:

支付宝付款流程的时间表

步骤11: 客户直接使用同步支付结果作为支付完成凭证，并根据状态码进行相应的接口处理；

第12步和第13步: 在第6步结束后，支付宝服务器将异步将签名的付款结果返回给我们的服务器，并且该服务器将使用支付宝公钥验证付款结果. 签名后，根据支付结果进行实际业务处理（如果支付成功，则在用户的money字段中加11，如果失败，则不进行处理等）；步骤13是服务器在处理后需要完成实际业务. 在其服务器SDK的回调中，业务处理结果返回到支付宝服务器（如果实际业务流程成功，则将其返回到支付宝服务器）如果交易完成，如果实际业务流程失败，它将返回到支付宝服务器，支付宝服务器将再次调用服务器SDK重新处理实际业务逻辑，直到成功为止，如果超过一定数量有时，服务器仍会向Alipay服务器返回故障，表明我们的系统有问题Alipay服务器不再触发服务器SDK重新处理实际业务，在这种情况下，我们的客户将致电我们的客户服务，说我的支付宝已经扣了钱，但是为什么没能成功充值，我们会手动与他人打交道.

上面已经说过: 添加订单信息并检查付款结果必须在服务器端完成，绝对不能在客户端完成.

以下是在客户端上对订单信息进行签名的过程，仅用于模拟服务器以显示如何通过签名最终将订单信息转换为orderString. 不要以为订单信息签名过程也可以放在客户端完成.

//将产品信息提供给AlixPayOrder的成员变量

订单*订单= [新订单];

//注意: app_id设置

order.app_id = appID;

//注意: 付款界面名称

order.method = @“ alipay.trade.app.pay”;

//注意: 参数编码格式

order.charset = @“ utf-8”;

//注意: 当前时间点

NSDateFormatter *格式化程序= [NSDateFormatter新]；

[formatter setDateFormat: @“ yyyy-MM-dd HH: mm: ss”];

order.timestamp = [格式符stringFromDate: [NSDate日期]];

//注意: 付款版本

order.version = @“ 1.0”;

//注意: sign_type设置

order.sign_type = @“ RSA”;

//注意: 产品数据

order.biz_content = [新的BizContent];

order.biz_content.body = @“我是测试数据”;

order.biz_content.subject = @“ 1”;

order.biz_content.out_trade_no = [self generateTradeNO]; //订单ID（由商家开发）

order.biz_content.timeout_express = @“ 30m”; //超时设置

order.biz_content.total_amount = [NSString stringWithFormat: @“％. 2f”，0.01]; //商品价格

app_id = 2015052600090779＆biz_content = {“ timeout_express”: “ 30m”，“ seller_id”: “”，“ product_code”: “ QUICK_MSECURITY_PAY”，“ total_amount”: “ 0.02”，“ subject”: “ 1”，“正文”: “我是测试数据”，“ out_trade_no”: “ ZQLM3O56MJD4SK3”}＆字符集= utf-8和方法= alipay.trade.app.pay＆sign_type = RSA2＆时间戳= 2016-07-28 20: 36: 11＆版本= 1.0

GsSZgPloF1vn52XAItRAldwQAbzIgkDyByCxMfTZG％2FMapRoyrNIJo4U1LUGjHp6gdBZ7U8jA1kljLPqkeGv8MZigd3kH25V0UK3Jc3C94Ngxm5S％2Fz5QsNr6wnqNY9sx％2Bw6DqNdEQnnks7PKvvU0zgsynip50lAhJmflmfHvp％2Bgk％3D

app_id = 2015052600090779＆biz_content = {“ timeout_express”: “ 30m”，“ seller_id”: “”，“ product_code”: “ QUICK_MSECURITY_PAY”，“ total_amount”: “ 0.02”，“ subject”: “ 1”支付sdk，“正文”: “我正在测试数据”，“ out_trade_no”: “ ZQLM3O56MJD4SK3”}＆字符集= utf-8＆方法= alipay.trade.app.pay＆sign_type = RSA2＆时间戳= 2016-07-28 20: 36: 11 ＆版本= 1.0＆符号= GsSZgPloF1vn52XAItRAldwQAbzIgkDyByCxMfTZG％2FMapRoyrNIJo4U1LUGjHp6gdBZ7U8jA1kljLPqkeGv8MZigd3kH25V0UK3Jc3C94Ngxm5S％2Fz5QsNr6wnqNY9sx％2Bw6DqNdEQnnks7PKvvU0zgsynip50lAhJmflmfHvp％2Bgk％3D

假设我们的服务器从支付宝服务器收到付款结果，即: 付款结果+数字签名.

因此我们的服务器将检查付款结果，如何检查？

微信支付的过程与支付宝基本相同. 两者之间最重要的区别是:

因此，在第二部分中，我们已经演示了支付宝的一般验证过程. 在这里，我们将介绍为上述第一个区别生成微信支付数字签名的验证过程:

---->传输---->

微信服务器验证:

可以看出，MD5加密也达到了签名和验证的效果. 验证的关键参数是应用程序的Api密钥. 当我们申请微信支付功能时，这个东西会填在平台上. 一个32个字符的字符串，因此只有我们的商人和微信才知道，因此使用Api密钥可实现公钥和私钥（如支付宝验证）的效果.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/ruanjian/article-225686-1.html