【转】AWS s3 V4签名算法

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

一、开篇说明：

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

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：
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
• 2.上传代码：
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  提醒：别忘了开启网络权限
• 3.简易源码流程图，数字代表行号：

  

  minio上传源码简易流程图

方案二：

demo下载：https://github.com/Nergal1/AWS-S3-demo

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

  1.  
  2.  

  权限：

  1.  
  2.  
  3.  
  4.  

  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）：
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
• 4.源码简易流程图，数字代表行号：

  

  aws sdk上传源码简易流程图

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

• • （1）指定的请求头有哪些？

    首先我们来看一个文件上传的请求：
    1.  
    2.  
    3.  
    4.  
    5.  
    6.  
    7.  
    8.  
    9.  
    10.  
    11.  
    12.  
    13.  
    14.  
    15.  
    1.  
    2.  
    3.  
    一大堆请求头，实际上根据 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.

      

      单块上传签名计算流程

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

1.  
2.  
3.  
4.  
5.  
6.  
7.  

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

1.  
2.  
3.  
4.  
5.  
6.  
7.  
8.  
9.  
10.  
11.  
12.  
13.  
14.  
15.  
16.  
17.  

• • • 第二种，多块传输
      多块上传请求头：
      x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD
      把有效荷载（请求body）分成几块，固定或可变大小的块。通过上传块，避免读取整个文件的有效荷载来计算签名.
• • • • a.第一块，计算所有的请求头的签名，空body请求
• • • • b.第二块，将第一个块的签名和有效载荷一起计算签名
• • • • c.第n块，将第n-1块的签名和有效载荷一起计算签名
• • • • d.最后，发送0 bytes的块包含第n块的签名。
        请求头Authorization中的Signature计算同单块上传：

        

        多块上传签名计算流程图

请求体中块签名计算：

请求体中比单块上传多了这些

chunk-signature的签名计算流程图