AWS s3 V4签名算法

秒速五厘米 2022-03-25 04:42 437阅读 0赞

原创，转载请注明：http://www.jianshu.com/p/a6a02309190f

一、开篇说明：  
以下思考方向，是以Android端为出发点（IOS同理）  
AWS:Amazon Web Services (亚马逊云服务)  
AWS s3 API文档：https://aws.amazon.com/cn/documentation/s3/

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70][]

Minio ：（具体的解释自行百度吧）一个基于 golang 语言开发的 AWS S3 存储协议的开源实现，并附带 web ui 界面，可以通过 Minio 搭建私人的兼容 AWS S3 协议的存储服务器。

二、需求分析  
项目需求：最近公司需要搭建一个文件服务器，让移动端（Android、ios）用来存储图片等文件。这个文件服务器后台使用minio搭建的。由于minio是基于AWS S3 存储协议，所以我们移动端也需要实现相同的协议来上传。移动端，我们确定了三种可行方案（方案优劣仅是基于对APK打包大小的影响程度来确定的）：

方案一：基于AWS S3 存储协议自己实现文件上传（最佳方案，最后项目引入文件最小----大约100K，不影响apk大小）  
方案二：使用AWS SDK 实现文件上传（中间方案，需要引入项目的jar包1.5M文件略大）  
方案三：使用minio SDK 实现文件上传（最差方案，需要引入6M jar包）  
三、代码实现  
由于项目需求不同，供大家自行选择，我将这三种方案实现一一说明。

方案三：  
demo下载：https://github.com/Nergal1/minio-demo

1.Android端引入minio SDK jar包会和原生的发生冲突，会报一些安全错误。  
引入时，去除冲突的包，com.fasterxml.jackson.core和com.google.code.findbugs：

dependencies {
                         compile ('io.minio:minio:3.0.4'){
                               excludegroup:'com.fasterxml.jackson.core'
                               excludegroup:'com.google.code.findbugs'
                          }
    }

2.上传代码：

/\*上传图片
    bucketName：服务端存储文件夹，必须先创建
    objectName:服务端存储文件名
    inputStream:上传文件流
    \*/
    minioClient.putObject(bucketName,objectName,inputStream,inputStream.available(),"application/octet-stream");

提醒：别忘了开启网络权限  
3.简易源码流程图，数字代表行号：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 1][]

minio上传源码简易流程图  
方案二：  
demo下载：https://github.com/Nergal1/AWS-S3-demo

1.由于AWS SDK源码中是开启Service，然后创建线程池实现异步上传、下载功能。  
清单文件要注册service：

权限：

android.permission.INTERNET
    android.permission.ACCESS_NETWORK_STATE
    android.permission.READ_EXTERNAL_STORAGE
    android.permission.WRITE_EXTERNAL_STORAGE
    Android 6.0+文件读写权限需要代码中实时获取，demo中未作兼容。如有文件问题，请自行添加。

2.引入jar包：  
aws-android-sdk-core-2.4.2.jar  
aws-android-sdk-s3-2.4.2.jar

3.先配置Constants.java中的ENDPOINT、ACCESSKEY、SecretKey、BUCKET\_NAME  
上传代码见UploadActivity.java（下载请自行查看DownloadActivity）：

TransferUtility transferUtility= Util.getTransferUtility(this);
    //上传
    TransferObserver observer =transferUtility.upload(Constants.BUCKET_NAME,file.getName(),
    file);
    //设置上传监听
    observer.setTransferListener(new UploadListener());

//监听类
    private class UploadListener implements TransferListener {
    // Simply updates the UI list when notified. 上传失败监听
    @Override
    public voidonError(intid,Exception e) {
    Log.e(TAG,"Error during upload: "+ id,e);
    updateList();
    }
    //上传进度监听
    @Override
    public voidonProgressChanged(intid, longbytesCurrent, longbytesTotal) {
    Log.d(TAG,String.format("onProgressChanged: %d, total: %d, current: %d",
    id,bytesTotal,bytesCurrent));
    updateList();
    }
    //上传状态监听
    @Override
    public voidonStateChanged(intid,TransferState newState) {
    Log.d(TAG,"onStateChanged: "+ id +", "+ newState);//例如：UploadActivity: onStateChanged: 9, FAILD 失败状态
    //            //根据id 查询文件路径
    //            TransferObserver transferObserver = transferUtility.getTransferById(id);
    //            Log.d(TAG, "文件地址---"+transferObserver.getAbsoluteFilePath());
    updateList();
    }
    }

4.源码简易流程图，数字代表行号：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 2][]

aws sdk上传源码简易流程图  
3.实现原理分析：  
实际上AWS S3 存储协议只不过是添加一些跟服务端协商的请求头，请求头的value是用AWS s3 V4签名算法算出来的。所以，上传时带上指定的请求头，以及合法的签名算法，其他地方跟普通上传没区别。服务端拿到请求头后，根据合法的签名算法，计算签名值，然后跟客户端请求头里的签名进行校验，成功后，服务端才允许上传。  
首先我们要解决两个问题：  
（1）指定的请求头有哪些？  
首先我们来看一个文件上传的请求：

--------------------------请求头--------------------------
    PUT /test/IMG_20170519_165644_1.jpg HTTP/1.1
    Content-MD5: 6PN5Zj06z+D5UkSG1ZxhNA==
    x-amz-decoded-content-length: 2566214
    x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD
    Content-Type: image/jpeg
    X-Amz-Date: 20170522T024116Z
    User-Agent: aws-sdk-android/2.4.2 Linux/3.10.86-g6be8ceb Dalvik/2.1.0/0 zh_CN TransferService/2.4.2
    aws-sdk-retry: 0/0
    Accept-Encoding: identity
    aws-sdk-invocation-id: 148858f7-e319-4578-b9f8-1b220f6af380
    Authorization: AWS4-HMAC-SHA256 Credential=1NA5K80UU85NMPK4BPEW/20170522/us-east-1/s3/aws4_request,SignedHeaders=content-md5;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length,Signature=db4e0abd4290730ed6fd27867d2fa342942372b88f1b5ad49b113ab9c77d6cc9
    Content-Length: 2568100
    Host: www.baidu.com
    Connection: Keep-Alive

--------------------------------------请求体--------------
    20000;chunk-signature=0cfa38451a889b866dbf43907ce3a72ee85f6b176168fb875903e8353366628e
    。。。二进制文件流。。。

一大堆请求头，实际上根据 S3 API 文档，Authorization请求头才是必要的  
而Authorization的value中SignedHeaders是规定了使用哪些请求头来计算本次请求的签名值。  
注意：SignedHeaders还规定了请求头的顺序。后面计算签名流程图中Canonical Request拼接请求头的顺序与SignedHeaders必须保持一致。  
也就是说content-md5;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length这些请求头计算出来Signature的值。根据S3 API 文档，SignedHeaders中host;x-amz-content-sha256;x-amz-date是必须存在的。  
那为什么本次请求还要加上content-md5，x-amz-decoded-content-length这两个值？  
我们来想想签名的作用：

*  a.验证请求身份

ACCESSKEY、SecretKey就是用来验证身份的，这两个参数也是计算Authorization的value中Signature的值所必须的。

*  b.防止篡改

SignedHeaders就是用来设置防止篡改的请求头的，content-md5是防止篡改请求内容（body）,x-amz-decoded-content-length防止篡改请求内容长度的。  
官方文档中，SignedHeaders必须的host;x-amz-content-sha256;x-amz-date这几个也就可以理解了，防止篡改请求地址，请求内容的sha256值，请求时间戳

*  c.防止请求签名被盗用

根据AWS S3 存储协议，时间戳（x-amz-date或Date请求头）15分钟内有效，没有权限的用户t通过截获已签名的request，可以篡改SignedHeaders中没有包含的部分，所以官方建议，签名所有请求头和请求体（也就是说SignedHeaders要尽量包含所有），还有最好用Https.

*  总结：

啰嗦一大堆，必要的请求头有哪些：Authorization、SignedHeaders中包含的（必须包含的有host;x-amz-content-sha256;x-amz-date），host，x-amz-content-sha256，x-amz-date这些请求头是服务端校验签名必须的。  
（2）签名算法是如何计算的？（即Authorization中的Signature）  
有两种签名算法：

*  第一种，单块传输(本人demo中使用的这种方式)

文件内存读取两次（一次计算文件sha256时，一次文件上传时）  
单块上传请求头：  
x-amz-content-sha256: 32e820d03db121caf97206f8cbcc6202cf25bf59246e8d6b0e8f6e3502d68f66  
或：x-amz-content-sha256: UNSIGNED-PAYLOAD（这种是单块不进行签名内容的写法）  
a.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 3][]

单块上传签名计算流程  
功能函数说明：  
Lowercase()：字符串转成小写.  
Hex()：base 16编码（全部小写）.  
SHA256Hash()：计算请求体body（上传文件时，body中只有文件，即计算文件的SHA256）的SHA256，然后base64.  
HMAC-SHA256():通过将key使用SHA256计算 HMAC

public static byte[]sumHmac(byte[] key, byte[] data)
    throwsNoSuchAlgorithmException,InvalidKeyException {
    Mac mac = Mac.getInstance("HmacSHA256");
    mac.init(newSecretKeySpec(key,"HmacSHA256"));
    mac.update(data);
    returnmac.doFinal();
    }

Trim():去空格.  
UriEncode()：  
a.保持'A'-'Z','a'-'z', '0'-'9', '-', '.', '\_', '~'不变  
b.空格字符必须转成"%20" (而不是 "+")  
c.byte编译成“%”后面跟两位的十六进制（字母大写）  
d.如果文件名（object name）类似“photos/Jan/sample.jpg”，其中包含“/”，不进行转义。

public static String UriEncode(CharSequence input, boolean
    encodeSlash) {
    StringBuilder result = new StringBuilder();
    for (int i = 0; i < input.length(); i++) {
    char ch = input.charAt(i);
    if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a'
    && ch <= 'z') || (ch >= '0' && ch <= '9') || ch == '_' ||
    ch == '-' || ch == '~' || ch == '.') {
    result.append(ch);
    } else if (ch == '/') {
    result.append(encodeSlash ? "%2F" : ch);
    } else {
    result.append(toHexUTF8(ch));
    }
    }
    return result.toString();
    }

*  第二种，多块传输

多块上传请求头：  
x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD  
把有效荷载（请求body）分成几块，固定或可变大小的块。通过上传块，避免读取整个文件的有效荷载来计算签名.

*  a.第一块，计算所有的请求头的签名，空body请求
 *  b.第二块，将第一个块的签名和有效载荷一起计算签名
 *  c.第n块，将第n-1块的签名和有效载荷一起计算签名
 *  d.最后，发送0 bytes的块包含第n块的签名。

请求头Authorization中的Signature计算同单块上传：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 4][]

多块上传签名计算流程图  
请求体中块签名计算：

![20190118162200836.png][]  
请求体中比单块上传多了这些

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 5][]  
chunk-signature的签名计算流程图

终于，说完了，第一次写这么长，讲的有不清楚的多多包涵，有什么问题可以给我留言，也可以发我邮箱18514689920@163.com.  
\---------------------  
作者：nergal\_  
来源：CSDN  
原文：https://blog.csdn.net/e491288767/article/details/72819606  
版权声明：本文为博主原创文章，转载请附上博文链接！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70]: /images/20220325/4e181870231742edbe0be82c5815458c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 1]: /images/20220325/6ad5b862f5c2476e8c57d2f28cd04fc9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 2]: /images/20220325/27c45050a33344d986795547fc3eaf9b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 3]: /images/20220325/6aa2c274246749f8bd6fcbaa45ddd7c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 4]: /images/20220325/49c81370e7b0421faa10eb95e097e8b9.png
[20190118162200836.png]: /images/20220325/b758f1b9ff89419dafd9e6cbc2f006ef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FpMjAwMGFp_size_16_color_FFFFFF_t_70 5]: /images/20220325/ee388647f4f24109a51c6440a6853bd8.png