加密

作者：岳明强 爱可生北京分公司 DBA 团队成员，人称强哥，负责数据库治理平台的运维和 MySQL 问题解决。善于对 MySQL 的故障定位。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 最近因为客户对于 MySQL 数据加密有一些要求，顺便对于 MySQL 的数据加密钻研了一下。以后 MySQL 原生的数据加密有动态加密，即加密数据库的物理文件，避免间接拖库后读取敏感数据，还有 SQL 级别的加密，只加密局部字段，即便获取到数据，也无奈进行解读。上面次要是对于 SQL 加密函数 AES_ENCRYPT() 的一些阐明 参数阐明解密：AES_DECRYPT()：AES_DECRYPT(crypt_str,key_str,init_vector,salt) 加密：AES_ENCRYPT(str,key_str,init_vector,salt) srt:加密之后的字符串 crypt_str：用来加密的字符串，加密后的字段长度能够用以下公式计算，其中 trunc() 示意小数局部舍弃，即如果输出单个字符，那么存储的字段长度即为最短长度16 16 * (trunc(string_length / 16) + 1)key_str：加密密钥，不倡议应用明文密钥，应该先用hash解决一下 init_vector 初始向量，用于块加密的模式（block_encryption_mode），默认的加密模式为aes-128-ecb，不须要初始向量，其它的加密模式（CBC、CFB1、CFB8、CFB128 和 OFB）都须要初始向量，其中 ecb 的加密模式并不平安，倡议应用其它的加密模式，应用 init_vector 加密后 也要应用雷同的 init_vector 解密 kdf_name,salt,info,iterations：为 KDF 的相干参数，绝对于更加平安，官网倡议应用，但因为版本要求过高（5.7.40以及8.0.30之后），这里就先不思考了 应用阐明应用官网 AES（高级加密规范）算法解密数据，默认应用128-bit也能够应用196或者256，密钥的长度与性能和平安度无关， 应用 AES_ENCRYPT(）对于基于 statement 的 binlog 类型是不平安的，倡议应用 SSL 连贯，避免将加密函数的明码和其它敏感值作为明文发送到服务器。 简略示例： mysql [localhost:5734] {root} (test) > show create table test;+-------+-----------------------------------------------------------------------------------------------------------------------+| Table | Create Table |+-------+-----------------------------------------------------------------------------------------------------------------------+| test | CREATE TABLE `test` ( `n` char(200) DEFAULT NULL, `t` int(11) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=latin1 |+-------+-----------------------------------------------------------------------------------------------------------------------+1 row in set (0.00 sec) mysql [localhost:5734] {root} (test) > insert into test values(aes_encrypt('b','test'),1);Query OK, 1 row affected (0.00 sec) mysql [localhost:5734] {root} (test) > select * from test;+----------------------------+------+| n | t |+----------------------------+------+| x | 0 || y | 0 || ùpñU!㿧ҟWHƒôò | 1 |+----------------------------+------+3 rows in set (0.00 sec) mysql [localhost:5734] {root} (test) > select aes_decrypt(n,'test') from test where t = 1;+-----------------------+| aes_decrypt(n,'test') |+-----------------------+| b |+-----------------------+1 row in set (0.00 sec)通过加密和压缩的后果返回二进制字符，所以倡议配置为VARBINARY或BLOB二进制字符串数据类型的列，避免字符集转换从而导致插入失败 ...

以电脑端操作为例： 一、首先咱们关上百度网盘，点击左侧——首页、我的文件，这里咱们能够看到有个新建文件夹，咱们能够建设一个文件夹用来辨别课程或其余视频。 二、新建文件夹填写名称后，双击关上，在下方会有一个上传文件的按钮，点击按钮选取要上传的视频加密文件后，抉择存入百度网盘 三、上传完毕后，右键点击文件夹抉择分享，会呈现一个创立连贯的页面，设置好信息后点击创立链接 四、复制链接关上微信或用其余形式粘贴发送就实现啦！

咱们要晓得点盾云属于视频加密软件，为了爱护视频的安全性，在播放时如果遇到具备录屏性能的软件开启，则会呈现一个提醒“检测到疑似开启录屏，近程类软件(QQ、钉钉、gamebar等)，请敞开该类程序后应用”而后就会退出播放。那遇到该提醒怎么解决呢？这个时候咱们就要检查一下是否开启了像最常见的QQ、钉钉这种软件了，如果开启那么敞开后就能够失常应用了，然而有时候QQ这些常见的利用敞开后还是有这个提醒，找不出是哪里的起因，这就有可能是电脑上自带一些录屏性能的软件在后盾自启动，那么学员反馈这个问题后，作为商家咱们怎么做呢？ 一、关上后盾治理，找到学员应用记录，输出有问题学员的激活码搜寻，会进去学员的信息 二、点击右侧疑似行为查看，就会看到是因为什么起因造成的，（如下图是因为QQ所引起） 三、将引起问题的程序名称发给学员，学员关上工作管理器找到该过程的名称敞开，留神这里须要在详细信息外面找，找到后敞开就能够了。 小编明天就写到这里啦！对于视频加密有什么不理解的能够一起探讨哦~

海绵宝宝的懊恼海绵宝宝十分喜爱网上购物，这让他感觉到被资本腐烂的高兴。 然而有一件事他始终感觉很麻烦，疾速上的收件单写满了他的个人信息，撕起来还很麻烦。 快递单号：202202181111收件人姓名：海绵宝宝收件人手机：138 8888 8888收件人地址：太平洋比基尼海滩比奇堡镇贝壳街124号的波萝屋备注：暗号是天王盖地虎你有没有遇到过和海绵宝宝一样的懊恼呢？又是怎么解决的呢？ 用户信息隐衷平安今天上线的需要小明往年 26 岁，是一名普普通通的上班族。在某互联网公司做技术开发。 “小明啊，有一个简略的需要。”，产品经理笑着朝小明走来。 “哦，又是简略的需要？”小明看了一下产品，“需要文档写了吗？” “简略的很，写啥文档呀。”，产品经理接着说，“和上次相似，加一个商品交易记录列表就行。这个需要很急哈，今天能上线吧？” “相似个锤子，上次的需要不也是做了一周。你把文档写分明，过一下需要，排期另说。”，小明也不受骗。 在具体设计实现之后，小明开始进行开发阶段。 写的还算比较顺利： public void doTransaction(TransactionDto dto) { // 输入日志 log.info("进行交易：{}", JSON.toJSON(dto)); // 执行业务解决 // 执行落库}TransactionDto 中蕴含了商品购买者的姓名、手机号、寓居地址以及交易的相干信息。 数据库中间接把响应的明文存储，页面间接列表展示。 这个需要很简略，小明想着，就等着测试验证了。 用户信息安全不过在代码评审的时候，项目经理却提出了一个问题，你的代码爱护用户的信息安全了吗？ （1）不应该日志中明文输入用户私人信息 （2）不应该页面中明文展现用户私人信息 （3）不应该在数据库中明文存储用户私人信息 并且以快递单号为例子，他应该如下： 快递单号：202202181111收件人姓名：海**宝收件人手机：138 **** 8888收件人地址：太平洋比基尼海滩比奇堡镇********备注：暗号是天王盖地虎这样的益处很显著，就算收件人不去撕掉这张单号，也不会裸露太多用户个人信息。 小明有些不了解，“不让日志输入，那怎么排查问题啊？” “你能够输入脱敏信息。禁止日志输入，就是防止能够查看日志的人，透露用户个人信息。” “那页面不让明文展现，经营怎么解决日常问题呢？” “页面能够增加明文显示的按钮，限定对应的权限，并且记录操作日志。” “数据库不让存储明文，那怎么玩啊？” “你能够去理解下可逆加密。”，项目经理顿了顿，“重写吧，再给你 2 天工夫。” “好吧”，小明有些失落。 技术实现的调整日志脱敏脱敏对于日志脱敏，小明能想到的最间接的办法，就是重载类的 toString() 方然，而后用工具类脱敏敏感信息。 不过他的共事老马给他举荐了一个基于注解的脱敏工具包，用起来还算不便： https://github.com/houbb/sensitive基于注解的日志脱敏。能够自定义策略实现，策略失效条件。常见的脱敏内置计划。java 深拷贝，且原始对象不必实现任何接口。反对用户自定义注解。反对基于 FastJSON 间接生成脱敏后的 json数据库可逆加密为了防止开发者、DBA、歹意攻击者等透露数据库信息，数据库中的敏感信息须要进行加密。 比方数据库中的手机号 phone 13066668888须要调整为如下： phone_chiper BABABABABABABABBABABABA # 加密之后的密文phone_mask 130****8888 # 手机号掩码phone_hash FFFFFFFFFFFFFFFFFFFFFFFF # 手机号哈希加密算法要求是可逆加密，如 AES/3DES/SM4 等。 ...

咱们要晓得点盾云属于视频加密软件，为了爱护视频的安全性，在播放时如果遇到具备录屏性能的软件开启，则会呈现一个提醒“检测到疑似开启录屏，近程类软件(QQ、钉钉、gamebar等)，请敞开该类程序后应用”而后就会退出播放。那遇到该提醒怎么解决呢？这个时候咱们就要检查一下是否开启了像最常见的QQ、钉钉这种软件了，如果开启那么敞开后就能够失常应用了，然而有时候QQ这些常见的利用敞开后还是有这个提醒，找不出是哪里的起因，这就有可能是电脑上自带一些录屏性能的软件在后盾自启动，那么学员反馈这个问题后，作为商家咱们怎么做呢? 一、关上后盾治理，找到学员应用记录，输出有问题学员的激活码搜寻，会进去学员的信息 二、点击右侧疑似行为查看，就会看到是因为什么起因造成的，（如下图是因为QQ所引起） 三、将引起问题的程序名称发给学员，学员关上工作管理器找到该过程的名称敞开，留神这里须要在详细信息外面找，找到后敞开就能够了。 小编明天就写到这里啦！对于视频加密有什么不理解的能够一起探讨哦~

密钥对，私钥，公钥基本概念密钥的分类具体过程 基本概念首先明确几个基本概念： 1、密钥对，在非对称加密技术中，有两种密钥，分为私钥和公钥，私钥是密钥对所有者持有，不可颁布，公钥是密钥对持有者颁布给别人的。 2、公钥，公钥用来给数据加密，用公钥加密的数据只能应用私钥解密。 3、私钥，如上，用来解密公钥加密的数据。 4、摘要，对须要传输的文本，做一个HASH计算，个别采纳SHA1，SHA2来取得。 5、数字签名，应用私钥对须要传输的文本的摘要进行加密，失去的密文即被称为该次传输过程的签名。 6、签名验证，数据接收端，拿到传输文本，然而须要确认该文本是否就是发送收回的内容，中途是否已经被篡改。因而拿本人持有的公钥对签名进行解密，失去了文本的摘要，而后应用与发送方同样的HASH算法计算摘要值，再与解密失去的摘要做比照，发现二者完全一致，则阐明文本没有被篡改过。 应用这个密钥对的时候，如果用其中一个密钥加密一段数据，必须用另一个密钥解密。比方用公钥加密数据就必须用私钥解密，如果用私钥加密也必须用公钥解密，否则解密将不会胜利。 密钥的分类对称密钥加密，又称私钥加密或会话密钥加密算法，即信息的发送方和接管方应用同一个密钥去加密和解密数据。它的最大劣势是加/解密速度快，适宜于对大数据量进行加密，但密钥治理艰难。 非对称密钥加密，又称公钥密钥加密。它须要应用不同的密钥来别离实现加密和解密操作，一个公开公布，即公开密钥，另一个由用户本人机密保留，即私用密钥。信息发送者用公开密钥去加密，而信息接收者则用私用密钥去解密。公钥机制灵便，但加密和解密速度却比对称密钥加密慢得多。 具体过程那么这里一共有两组四个密钥：A的公钥（PUB_A），A的私钥（PRI_A）；B的公钥（PUB_B），B的私钥（PRI_B）。 公钥个别用来加密，私钥用来签名。 公钥和私钥惟一对应，用某个公钥签名过得内容只能用对应的私钥能力解签验证；同样用某个私钥加密的内容只能用对应的公钥能力解密。 这时A向B发送信息的整个签名和加密的过程如下：1、A先用本人的私钥（PRI_A）对信息（个别是信息的摘要）进行签名。2、A接着应用B的公钥（PUB_B）对信息内容和签名信息进行加密。 这样当B接管到A的信息后，获取信息内容的步骤如下：1、用本人的私钥（PRI_B）解密A用B的公钥（PUB_B）加密的内容；2、失去解密后的明文后用A的公钥（PUB_A）解签A用A本人的私钥（PRI_A）的签名。 从而整个过程就保障了开始说的端到端的惟一确认。A的签名只有A的公钥能力解签，这样B就能确认这个信息是A发来的；A的加密只有B的私钥能力解密，这样A就能确认这份信息只能被B读取。上面的例子很好了解释了这个问题。how to get public key from private keycreate rsa dsa key with opensslFix ssl key values mistch issuesetup ssh key to login Linuxwhich ssh key is secure

咱们都晓得视频加密软件次要的目标就是为了爱护视频的安全性，很多人在理解的时候不晓得先从哪些方面去理解，那么能够先理解一下它的性能方面，因为一个产品到底适不适宜本人，首先得先看可不可以满足本人的需要，那这些性能都是怎么做的呢？明天小编就带大家一起来理解一下对于性能方面的小常识吧！作为一款视频加密的软件，所蕴含的性能大抵如下： 1. 高强度加密算法：采取逐帧加密，加密后的视频文件具备防逆向破解性能，点盾云视频加密软件可避免非法复制、破解和数据篡改。 2.智能防录屏机制/防硬件采集：软件能够自动检测各种已知和未知的翻录软件，截屏软件，并且实时上传信息，后盾可查，限度高清接口局部性能，进而避免硬件设施采集视频。 3.反对离线观看：三种创立模式均能反对离线观看，预创立、预申请两种模式想要离线观看，可设置在联网激活后反对10次离线观看，10次后再次联网激活就可。 4.一机一码：输出激活码激活后会主动绑定设施，无效避免了多人共享视频。 5.解冻与召回：可用于某些非凡状况，如：退款，保障视频平安。 5.多平台播放：反对Windows，安卓手机/平板，iPhone/ iPad，Mac多端应用 6.后盾管理系统：后盾提供课程管理、激活码治理，还能够查看学员的设施信息，激活状态及疑似行为等。 以上就是举例的点盾云所蕴含的根底性能啦！还能够设置限度播放日期等小细节性能点，具体的性能能够本人实际上手操作试用哦！

明码的世界如果你是黑帮老大，平时和手下沟通，如何保障本人的信息安全呢？ 在神探夏洛克的第一季中，就讲述了一个如何侦破黑帮的加密交换的故事。 这种明码利用的是明码字典。 明码自身能够是一本书，比方常见的《圣经》、《杀死一只知更鸟》，或者纽约地图？ 这种加密形式的长处就是如果不晓得字典自身，根本无奈破解。应用起来也非常简单，甚至你能够定期和手下更换字典。 谈到明码，另一个不得不提的故事就是二战时期的明码破译问题。 二战时期，德国创造的 ENIGMA 加密机器，让通信加密从人工手写时代逾越到了机器操作时代，也让人工破译有些无能为力。 为了破译德国的这套加密机器，从剑桥找来了三位优良的数学家：杰弗里期、威尔仕曼、阿兰.图灵。 说到图灵，我想大家肯定都晓得，如果不晓得，倡议珍藏本篇文章，理解之后再持续浏览。 常言道，唯有魔法能够战胜魔法。那能够让奇怪博……啊，不好意思，还是让图灵来吧。 图灵认为使用数学上的 crib 办法来破解 ENIGMA 是可行的，在前期破译了大部分的德军情报信息。 当前的时代，咱们用机器去战胜机器。 加密的可逆性加密算法咱们整体能够分为：可逆加密和不可逆加密；可逆加密又能够分为：对称加密和非对称加密。 当然个别的通信中，咱们都是须要进行解密的。 本文次要介绍近代最有名的四大加密算法：DES 3DES AES 和 SM4。 DES 算法简介DES 全称为 Data Encryption Standard，即数据加密规范，是一种应用密钥加密的块算法，1977年被美国联邦政府的国家标准局确定为联邦材料解决规范（FIPS），并受权在非密级政府通信中应用，随后该算法在国内上宽泛流传开来。 设计准则DES设计中应用了分组明码设计的两个准则：混同（confusion）和扩散(diffusion)，其目标是抗击敌手对明码零碎的统计分析。 混同是使密文的统计个性与密钥的取值之间的关系尽可能复杂化，以使密钥和明文以及密文之间的依赖性对明码剖析者来说是无奈利用的。 扩散的作用就是将每一位明文的影响尽可能迅速地作用到较多的输入密文位中，以便在大量的密文中打消明文的统计构造，并且使每一位密钥的影响尽可能迅速地扩大到较多的密文位中，以防对密钥进行逐段破译。 ps: 根本近代的加密算法应该遵循这两个准则，否则就会被统计攻打。 入门应用这里提供了最简略的 DES 实现例子。 import javax.crypto.*;import javax.crypto.spec.DESKeySpec;import java.io.UnsupportedEncodingException;import java.security.InvalidKeyException;import java.security.NoSuchAlgorithmException;import java.security.SecureRandom;import java.security.spec.InvalidKeySpecException;/** * DES 工具类 * * @author binbin.hou * @since 0.0.6 */public final class DesUtil { private DesUtil() { } /** * des * * @since 0.0.6 */ private static final String DES = "DES"; /** * 加密 * * @param plainText 待加密内容 * @param password 明码 * @return 加密后果 * @since 0.0.6 */ public static byte[] encrypt(String plainText, String password) { byte[] bytes = plainText.getBytes(); return encrypt(bytes, password); } /** * 加密 * * @param plainText 待加密内容 * @param password 明码 * @return 加密后果 * @since 0.0.6 */ public static byte[] encrypt(byte[] plainText, String password) { try { SecureRandom random = new SecureRandom(); DESKeySpec desKey = new DESKeySpec(password.getBytes()); // 创立一个密匙工厂，而后用它把DESKeySpec转换成 SecretKeyFactory keyFactory = SecretKeyFactory.getInstance(DES); SecretKey secretKey = keyFactory.generateSecret(desKey); // Cipher对象理论实现加密操作 Cipher cipher = Cipher.getInstance(DES); // 用密匙初始化Cipher对象 cipher.init(Cipher.ENCRYPT_MODE, secretKey, random); // 当初，获取数据并加密 // 正式执行加密操作 return cipher.doFinal(plainText); } catch (Exception e) { throw new SecretRuntimeException(e); } } /** * 解密 * * @param src byte[] * @param password String * @return 解密后果 * @since 0.0.6 */ public static byte[] decrypt(byte[] src, String password) { try { // DES算法要求有一个可信赖的随机数源 SecureRandom random = new SecureRandom(); // 创立一个DESKeySpec对象 DESKeySpec desKey = new DESKeySpec(password.getBytes()); // 创立一个密匙工厂 SecretKeyFactory keyFactory = SecretKeyFactory.getInstance(DES); // 将DESKeySpec对象转换成SecretKey对象 SecretKey secretKey = keyFactory.generateSecret(desKey); // Cipher对象理论实现解密操作 Cipher cipher = Cipher.getInstance(DES); // 用密匙初始化Cipher对象 cipher.init(Cipher.DECRYPT_MODE, secretKey, random); // 真正开始解密操作 return cipher.doFinal(src); } catch (InvalidKeyException | NoSuchAlgorithmException | InvalidKeySpecException | NoSuchPaddingException | IllegalBlockSizeException | BadPaddingException e) { throw new SecretRuntimeException(e); } } /** * 解密 * * @param src byte[] * @param password String * @return 解密后果 * @since 0.0.6 */ public static String decryptToString(byte[] src, String password, String charset) { try { byte[] bytes = decrypt(src, password); return new String(bytes, charset); } catch (UnsupportedEncodingException e) { throw new SecretRuntimeException(e); } } /** * 解密 * * @param src byte[] * @param password String * @return 解密后果 * @since 0.0.6 */ public static String decryptToString(byte[] src, String password) { return decryptToString(src, password, "UTF-8"); }}测试代码测试代码如下： ...

前言在咱们日常开发中，咱们可能很随便把数据库明码间接明文裸露在配置文件中，在开发环境能够这么做，然而在生产环境，是相当不倡议这么做，毕竟平安无小事，谁也不晓得哪天明码就莫名其妙泄露了。明天就来聊聊在springboot我的项目中如何对数据库明码进行加密 注释计划一、应用druid数据库连接池对数据库明码加密1、pom.xml引入druid包为了不便其余的操作，这边间接引入druid的starter <dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>${druid.version}</version> </dependency>2、利用com.alibaba.druid.filter.config.ConfigTools生成公私钥ps： 生成的形式有两种，一种利用命令行生成，一种间接写个工具类生成。本文示例间接采纳工具类生成 工具类代码如下 /** * alibaba druid加解密规定： * 明文明码+私钥(privateKey)加密=加密明码 * 加密明码+公钥(publicKey)解密=明文明码 */public final class DruidEncryptorUtils { private static String privateKey; private static String publicKey; static { try { String[] keyPair = ConfigTools.genKeyPair(512); privateKey = keyPair[0]; System.out.println(String.format("privateKey-->%s",privateKey)); publicKey = keyPair[1]; System.out.println(String.format("publicKey-->%s",publicKey)); } catch (NoSuchAlgorithmException e) { e.printStackTrace(); } catch (NoSuchProviderException e) { e.printStackTrace(); } } /** * 明文加密 * @param plaintext * @return */ @SneakyThrows public static String encode(String plaintext){ System.out.println("明文字符串：" + plaintext); String ciphertext = ConfigTools.encrypt(privateKey,plaintext); System.out.println("加密后字符串：" + ciphertext); return ciphertext; } /** * 解密 * @param ciphertext * @return */ @SneakyThrows public static String decode(String ciphertext){ System.out.println("加密字符串：" + ciphertext); String plaintext = ConfigTools.decrypt(publicKey,ciphertext); System.out.println("解密后的字符串：" + plaintext); return plaintext; }3、批改数据库的配置文件内容信息a 、 批改明码 ...

在应用 Helm 部署应用程序时，咱们常常会遇到须要为所要部署的应用程序设定敏感信息值的状况，如：为应用程序本身设定登陆名和明码信息，或设定应用程序连贯数据库时所需的信息等等。 若将这些蕴含了敏感信息的值间接以明文的形式存储在自定义的 Values 文件中，尤其是当应用如 Git 等代码版本控制工具追踪 Values 文件时，将会带来十分大的安全隐患。 因而，咱们通常不会将这些蕴含有敏感信息的值保留在 Values 文件中，而是在部署的过程中，通过 HELM 命令的 --set 参数，以命令行的模式为这些变量设定值。 但应用这种形式同样也有它本身的局限性：首先，如果要设定的敏感字段过多，则在命令行中须要指定的参数就越多，这将使得命令行过于简短且容易出错，同时部署人员须要记住的部署参数也变得复杂起来；其次，通过查看零碎执行过的命令历史记录，同样可能获取到在执行 HELM 命令时所有指定的敏感信息参数，这在肯定水平上同样存在安全隐患。 而本文将介绍另一种相对来说比拟完满的解决方案：利用 Helm 的 secrets 插件，将这些蕴含了敏感信息的值通过某种加密伎俩加密之后，在保留到 Values 文件中去。 HELM SECRETS 插件简介helm-secrets 插件能够帮忙咱们将定义在 values.yaml 文件中的值进行加密之后从新存储到 Values 文件中，被加密后的 Values 文件能够被随便散发、存储到代码版本管理工具中而不必放心敏感信息被裸露。上面是一个加密后的 Values 文件示例： #ENC[AES256_GCM,data:IHAqGPYHlUdD2+xSn5ZcYCo=,iv:1KKx8l1zl41LuNYcKw3biXm0vx+vjAeA7wdnNHYjQ6Y=,tag:MmWG4SIeXPt0o0HOHGtJeQ==,type:comment]registry: url: ENC[AES256_GCM,data:sYON9+wBDq9jcmhy8iUaITpIjApLbys=,iv:z/ITKkJp2rS/jMyvxghweA+7W0QlZ98PR+4gDGhX+WI=,tag:TLbCkMcIfW30/80FpaozoA==,type:str] username: ENC[AES256_GCM,data:5Ju2bxk=,iv:hxRUoi0lViW7chOQTiyZyt4nGMS5V5YZyFNf19LmvpA=,tag:lb830A5pnZ4bI0HUosyc7Q==,type:str] password: ENC[AES256_GCM,data:1WmPZCSlzGbSn2LqMc7DmHjQKTjsaPUdn9nMKvbl+KIJ451EPkV0s3dqF+NVZ5E+T6reYN/lY7Ok3VmGvboVAbFs1IYzn7KenbGLMGgCT+JhUFaYz16TeGGsyWDk6YcIIw/XzR6lTjilpHF+DuZuepOyiAnCO0Q5k4aux2lICQh6P8mOezt8flP9/blnFGVZhaaE5r5vT6hsaQbsy7Rnk2lP926xT8NWcaXR85AleRvevQ/zwFIFjjk=,iv:ivA6U20LCHOoR9WGSmuvlJdhnYx/ZC8Pw9czMjNrrlI=,tag:wX3SiiBv8OjSZkpbCznDZw==,type:str]jenkins: master: JCasC: configScripts: credentials-config: ENC[AES256_GCM,data:3dN7KBW...Ov/rsUA=,tag:qlfV/0x0vr45JxMYM1UdMQ==,type:str]sops: kms: [] gcp_kms: [] lastmodified: '2019-07-10T06:21:36Z' mac: ENC[AES256_GCM,data:sKsL25V5yci+oD1PpfA5fU6zE7YCc6Sxg7myE4eqoDcA+guG8gUg4Hcj5yAB4APBq3+KtPIXoF0hNHVYZOOYqZXQrMpO0jASjWHmLAFTUb6FE6xOtb4mP3FBk8W6Km7TfNz3Te8WW4nsb/+c0WmFSQnIolaeXgbbZhZ23x+V9g=1,iv:Oha7rwD2y3xCc+UnI+xXwrnFByMhNJkF84TiYq4/LsWI=,tag:W3e9ox2G9QL5jQEV0VwGA==,type:str] pgp: - created_at: '2019-07-10T06:21:34Z' enc: | -----BEGIN PGP MESSAGE----- hQEMA9Q2nDmrg55qAQf/aXiC7EXZlP5OZDrH3clCb0I9uqP8eNhVgAzqyfSaajGB ... =h7fE -----END PGP MESSAGE----- fp: AD331C18082B4669992805DDCB8EA0C7BC44A464 unencrypted_suffix: _unencrypted version: 3.0.3能够看到，加密操作仅仅是针对 YAML 文件中所有 Key 对应的值进行的，而保留了 Key 本真。绝对于那种针对整个 YAML 文件进行整体加密的形式来说，通过这种加密形式加密后的文件，依然保留了很强的可读性，这使得咱们对加密后的 YAML 文件进行保护变的可能。 ...

摘要：如何增强技术层面的数据安全和隐衷爱护，对数据仓库产品自身提出更多的性能要求，也是数据安全建设最卓有成效的方法。本文分享自华为云社区《GaussDB(DWS)平安：隐衷爱护现真招儿——数据脱敏》，原文作者：wo华哒哒。 引言大数据时代的到来，颠覆了传统业态的运作模式，激发出新的生产潜能。数据成为重要的生产因素，是信息的载体，数据间的流动也潜藏着更高阶维度的价值信息。对于数据控制者和数据处理者而言，如何最大化数据流动的价值，是数据挖掘的初衷和意义。然而，一系列信息泄露事件的曝光，使得数据安全越来越受到宽泛的关注。 各国各地区逐渐建立健全和欠缺数据安全与隐衷爱护相干法律法规，提供用户隐衷爱护的法律保障。如何增强技术层面的数据安全和隐衷爱护，对数据仓库产品自身提出更多的性能要求，也是数据安全建设最卓有成效的方法。 什么是数据脱敏？数据脱敏（Data Masking），顾名思义，是屏蔽敏感数据，对某些敏感信息（比方，身份证号、手机号、卡号、客户姓名、客户地址、邮箱地址、薪资等等 ）通过脱敏规定进行数据的变形，实现隐衷数据的牢靠爱护。业界常见的脱敏规定有，替换、重排、加密、截断、掩码，用户也能够依据冀望的脱敏算法自定义脱敏规定。 通常，良好的数据脱敏施行，须要遵循如下两个准则，第一，尽可能地为脱敏后的利用，保留脱敏前的有意义信息；第二，最大水平地避免黑客进行破解。 数据脱敏分为静态数据脱敏和动态数据脱敏。静态数据脱敏，是数据的“搬移并仿真替换”，是将数据抽取进行脱敏解决后，下发给上游环节，随便取用和读写的，脱敏后数据与生产环境相隔离，满足业务需要的同时保障生产数据库的平安。动态数据脱敏，在拜访敏感数据的同时实时进行脱敏解决，能够为不同角色、不同权限、不同数据类型执行不同的脱敏计划，从而确保返回的数据可用而平安。 GaussDB (DWS)的数据脱敏性能，摒弃业务应用层脱敏依赖性高、代价大等痛点，将数据脱敏内化为数据库产品本身的平安能力，提供了一套残缺、平安、灵便、通明、敌对的数据脱敏解决方案，属于动态数据脱敏。用户辨认敏感字段后，基于指标字段，绑定内置脱敏函数，即可创立脱敏策略。脱敏策略（Redaction Policy）与表对象是一一对应的。一个脱敏策略蕴含表对象、失效条件、脱敏列-脱敏函数对三个要害因素，是该表对象上所有脱敏列的汇合，不同字段能够依据数据特色采纳不同的脱敏函数。当且仅当失效条件为真时，查问语句才会触发敏感数据的脱敏，而脱敏过程是内置在SQL引擎外部实现的，对生成环境用户是通明不可见的。 怎么用数据脱敏？动态数据脱敏，是在查问语句执行过程中，依据失效条件是否满足，实现实时的脱敏解决。失效条件，通常是针对以后用户角色的判断。敏感数据的可见范畴，即是针对不同用户预设的。系统管理员，具备最高权限，任何时刻对任何表的任何字段都可见。确定受限制用户角色，是创立脱敏策略的第一步。 敏感信息依赖于理论业务场景和平安维度，以自然人为例，用户个体的敏感字段包含：姓名、身份证号、手机号、邮箱地址等等；在银行零碎，作为客户，可能还波及银行卡号、过期工夫、领取明码等等；在公司零碎，作为员工，可能还波及薪资、教育背景等；在医疗系统，作为患者，可能还波及就诊信息等等。所以，辨认和梳理具体业务场景的敏感字段，是创立脱敏策略的第二步。 产品内置一系列常见的脱敏函数接口，能够针对不同数据类型和数据特色，指定参数，从而达到不一样的脱敏成果。脱敏函数可采纳如下三种内置接口，同时反对自定义脱敏函数。三种内置脱敏函数可能涵盖大部分场景的脱敏成果，不举荐应用自定义脱敏函数。 MASK_NONE：不作脱敏解决，仅内部测试用。MASK_FULL：全脱敏成固定值。MASK_PARTIAL：应用指定的脱敏字符对脱敏范畴内的内容做局部脱敏。不同脱敏列能够采纳不同的脱敏函数。比方，手机号通常显示后四位尾号，后面用"*"替换；金额对立显示为固定值0，等等。确定脱敏列须要绑定的脱敏函数，是创立脱敏策略的第三步。 以某公司员工表emp，表的属主用户alice以及用户matu、july为例，简略介绍数据脱敏的应用过程。其中，表emp蕴含员工的姓名、手机号、邮箱、发薪卡号、薪资等隐衷数据，用户alice是人力资源经理，用户matu和july是一般职员。 假如表、用户及用户对表emp的查看权限均已就绪。 （1）创立脱敏策略mask_emp，仅容许alice查看员工所有信息，matu和july对发薪卡号、薪资均不可见。字段card_no是数值类型，采纳MASK_FULL全脱敏成固定值0；字段card_string是字符类型，采纳MASK_PARTIAL按指定的输入输出格局对原始数据作局部脱敏；字段salary是数值类型，采纳数字9局部脱敏倒数第二位前的所有数位值。postgres=# CREATE REDACTION POLICY mask_emp ON emp WHEN (current_user != 'alice')ADD COLUMN card_no WITH mask_full(card_no),ADD COLUMN card_string WITH mask_partial(card_string, 'VVVVFVVVVFVVVVFVVVV','VVVV-VVVV-VVVV-VVVV','#',1,12), ADD COLUMN salary WITH mask_partial(salary, '9', 1, length(salary) - 2);切换到matu和july，查看员工表emp。 postgres=> SET ROLE matu PASSWORD 'Gauss@123';postgres=> SELECT * FROM emp; id | name | phone_no | card_no | card_string | email | salary | birthday ----+------+-------------+---------+---------------------+----------------------+------------+--------------------- 1 | anny | 13420002340 | 0 | ####-####-####-1234 | smithWu@163.com | 99999.9990 | 1999-10-02 00:00:00 2 | bob | 18299023211 | 0 | ####-####-####-3456 | 66allen_mm@qq.com | 9999.9990 | 1989-12-12 00:00:00 3 | cici | 15512231233 | | | jonesishere@sina.com | | 1992-11-06 00:00:00(3 rows)postgres=> SET ROLE july PASSWORD 'Gauss@123';postgres=> SELECT * FROM emp; id | name | phone_no | card_no | card_string | email | salary | birthday ----+------+-------------+---------+---------------------+----------------------+------------+--------------------- 1 | anny | 13420002340 | 0 | ####-####-####-1234 | smithWu@163.com | 99999.9990 | 1999-10-02 00:00:00 2 | bob | 18299023211 | 0 | ####-####-####-3456 | 66allen_mm@qq.com | 9999.9990 | 1989-12-12 00:00:00 3 | cici | 15512231233 | | | jonesishere@sina.com | | 1992-11-06 00:00:00(3 rows)（2）因为工作调整，matu进入人力资源部参加公司招聘事宜，也对员工所有信息可见，批改策略失效条件。postgres=> ALTER REDACTION POLICY mask_emp ON emp WHEN(current_user NOT IN ('alice', 'matu'));切换到用户matu和july，从新查看员工表emp。 ...

前言Kubernetes 曾经毫无争议地成为了云原生时代的事实标准，在 Kubernetes 上部署应用程序也变得简略起来（无论是采纳 kustomize 还是 helm），尽管对于敏感信息（比方用户名、明码、token 和证书等）的解决，Kubernetes 本人提供了 secret 这种形式，但其是一种编码方式，而非加密形式，如果须要用版本控制系统（比方 git）来对所有的文件、内容等进行版本控制时，这种用编码来解决敏感信息的形式就显得很不平安了（即便是采纳公有库），这一点在实现 GitOps 时，是一个痛点。 基于此，本文就介绍三种能够加密 Kubernetes secret 的形式：Sealed Secrets、Helm Secrets 和 Kamus。 一、Sealed SecretsSealed Secrets 充分利用 kuberntes 的高扩展性，通过 CRD 来创立一个 SealedSecret 对象，通过将加密的内容存储在扩大 SealedSecret 对象中，而 SealedSecret 只可能被运行于指标集群上的 controller 解密，其余人员和形式都无奈正确解密原始数据。SealedSecret 对象同时又会生成与其名称雷同的 secret 对象，随后就能够依照惯例形式应用 secret 对象了。最初将加密后的文件间接推送至版本控制系统即可，而不必放心敏感信息被透露。 1.1 原理Sealed Secrets 加解密的原理简略来说就是：装置的时候 controller 会生成一对用于加密的 key，加密时在客户端 kubeseal 的帮忙下，将蕴含敏感信息的 kubernets secrets 内容加密转变为一个蕴含有加密信息的 Kubernetes SealedSecrets 对象；解密时在 controller 的帮忙下将 Kubernetes SealedSecrets 对象内的内容进行解密，而后生成惯例的 kubernetes secret 对象。 上面分加解密两局部（encryption 和 decryption）来介绍 Sealed Secrerts 的工作原理。 ...

摘要：数据加密作为无效避免未受权拜访和防护数据泄露的技术，在各种信息系统中宽泛应用。作为信息系统的外围，GaussDB(DWS)数仓也提供数据加密性能，包含通明加密和应用SQL函数加密。本文分享自华为云社区《你应该晓得的数仓平安——加密函数》，原文作者：zhangkunhn 。 数据泄露防护数据作为信息系统中的外围资产，其机密性、完整性和可用性必须失去保障，以防止数据被非法透露或非法篡改。以后数据泄露事件层出不穷，给集体和企业造成重大损失。 避免数据泄露能够有两种技术门路。一是权限治理，采纳最小化受权准则对应用数据的用户和应用程序受权。另一种是数据加密，包含应用SQL函数加密和通明加密。权限治理在你应该晓得的数仓平安——默认权限实现共享schema一文中有所介绍。本文探讨通明加密，后续博文再谈谈SQL函数加密。 通明加密的利用场景通明加密可能保障用户数据安全。更换磁盘、磁盘流出或者运维非法间接读取磁盘文件会绕过认证、权限治理和审计，从而导致数据泄露的危险。客户对业务数据有很高机密性要求时倡议应用通明加密。 通明加密的原理通明加密性能是对存在硬盘上的用户数据加密存储，对用户及下层应用SQL的利用不感知。通明的含意是指对客户来说是无感知的，仅须要创立GaussDB(DWS)集群时配置通明加密。目前反对行存表和列存表文件的加密存储，反对集群级别的通明加密配置。 集群级别的通明加密意味着集群中的所有库，库中的所有表都是加密存储。集群级别的通明加密还意味着须要在创立集群时进行配置，集群创立之后不可批改，既不能将非加密集群批改为加密集群，也不能将加密集群批改为非加密集群。 加密算法通明加密外围是算法和密钥。咱们采纳AES-128算法，加密模式应用CTR。CTR流加密能够保障明文和密文长度相等，不会导致加密后数据存储空间收缩。 密钥治理应用华为私有云KMS服务治理，保障了用户的密钥平安。加密密钥层次结构有三层。按层次结构顺序排列，这些密钥为主密钥（CMK）、集群密钥 (CEK)、数据库密钥 (DEK)。 主密钥保留在KMS中，用于给CEK加密。CEK用于加密DEK，CEK明文保留在集群内存中，密文保留在服务治理面中。DEK用于加密数据库中的数据，DEK明文保留在集群内存中，密文保留在服务治理面中。 密钥轮转出于平安思考，用户能够执行密钥轮转操作。密钥轮转只轮转集群密钥，不管转数据库秘钥。 通明加密的后续演进集群级通明加密的长处是所有数据包含用户表和零碎表都加密，实用于所有加密需要。一枚硬币的两面性通知咱们，长处也可能是毛病。对所有数据库对象加密会对数据导入和查问带来性能上的开销。 为解决此问题，后续思考反对细粒度通明加密。比方能够反对表级通明加密，用户在创立表时指定属性为加密表，该用户表的数据会加密存储。用户能够在蕴含敏感数据的表中开启加密属性，在查问和应用过程中不感知加解密过程。因为加密粒度较小，对性能的影响也较小。 总结通明加密是保障用户外围数据安全的无效伎俩。从应用场景和原理介绍了GaussDB(DWS)数仓的通明加密个性，指出了后续通明加密个性的钻研方向。 加密算法介绍密码学中明码算法能够分为三类：哈希函数、对称明码算法和非对称明码算法。 哈希函数哈希函数又称为摘要算法，对于数据$$data$$，$$Hash$$函数会生成固定长度的数据，即$$Hash(data)=result$$。这个过程是不可逆的，即Hash函数不存在反函数，无奈由$$result$$失去$$data$$。在不应保留明文场景，比方口令(password)属于敏感信息，系统管理员用户也不应该晓得用户的明文口令，就应该应用哈希算法，存储口令的单向哈希值。 理论应用中会退出盐值和迭代次数，防止雷同口令生成雷同的哈希值，以避免彩虹表攻打。 对称明码算法对称明码算法应用雷同的密钥来加密和加密数据。对称明码算法分为分组明码算法和流明码算法。 分组明码算法将明文分成固定长度的分组，用密钥对每个分组加密。因为分组长度固定，当明文长度不是分组长度的整数倍时，会对明文做填充解决。因为填充的存在，分组明码算法失去的密文长度会大于明文长度。 流明码算法将明文逐比特与密钥流运算。流明码算法不须要填充，失去的密文长度等于明文长度。 非对称明码算法非对称明码算法，又称为公钥明码算法。算法应用两个密钥：公钥和私钥。公钥向所有人公开，私钥窃密。非对称明码算法利用于密钥协商、数字签名、数字证书等畛域。 加密函数SQL接口GaussDB(DWS)次要提供了哈希函数和对称明码算法。哈希函数反对sha256, sha384, sha512和国密sm3。对称明码算法反对aes128, aes192, aes256和国密sm4。 哈希函数md5(string)将string应用MD5加密，并以16进制数作为返回值。MD5的安全性较低，不倡议应用。 gs_hash(hashstr, hashmethod)以hashmethod算法对hashstr字符串进行信息摘要，返回信息摘要字符串。反对的hashmethod：sha256, sha384, sha512, sm3。 testdb=# SELECT gs_hash('GaussDB(DWS)', 'sha256'); gs_hash ------------------------------------------------------------------ cc2d1b97c6adfba44bbce7386516f63f16fc6e6a10bd938861d3aba501ac8aab(1 row)对称明码算法gs_encrypt(encryptstr, keystr, cryptotype, cryptomode, hashmethod)采纳cryptotype和cryptomode组成的加密算法以及hashmethod指定的HMAC算法，以keystr为密钥对encryptstr字符串进行加密，返回加密后的字符串。反对的cryptotype：aes128, aes192, aes256, sm4。反对的cryptomode：cbc。反对的hashmethod：sha256, sha384, sha512, sm3。testdb=# SELECT gs_encrypt('GaussDB(DWS)', '1234', 'aes128', 'cbc', 'sha256'); gs_encrypt -------------------------------------------------------------------------------------------------------------------------- AAAAAAAAAADlzZYiNQK1uB+p1gza4Lu3Moj3HdP4E1uJmqfDYBaXDLMt7RZoE0YVx9h2dMRYBQ5fhFNqqM49sUkeS72o8kX5vWRQvfW3fuocGyp+b+lX9A==(1 row)gs_decrypt(decryptstr, keystr，cryptotype, cryptomode, hashmethod)采纳cryptotype和cryptomode组成的加密算法以及hashmethod指定的HMAC算法，以keystr为密钥对decryptstr字符串进行解密，返回解密后的字符串。解密应用的keystr必须保障与加密时应用的keystr统一能力失常解密。testdb=# SELECT gs_decrypt('AAAAAAAAAADlzZYiNQK1uB+p1gza4Lu3Moj3HdP4E1uJmqfDYBaXDLMt7RZoE0YVx9h2dMRYBQ5fhFNqqM49sUkeS72o8kX5vWRQvfW3fuocGyp+b+lX9A==', '1234', 'aes128', 'cbc', 'sha256'); gs_decrypt -------------- GaussDB(DWS)(1 row)利用举例有个student表，有id，name和score三个属性。name能够应用哈希函数加密保留，score能够应用对称明码算法保留。 ...

简介内容嗅探，也被称为媒体类型嗅探或MIME嗅探，是查看一个字节流的内容，试图推断其中数据的文件格式的做法。内容嗅探通常用在媒体类型没有被精确指定的状况，用于弥补元数据信息。 本文将会解说内容嗅探的罕用场景和可能呈现的问题。 MIME typesMIME的全称是Multipurpose Internet Mail Extensions，多用途互联网邮件扩大。它是一种规范，它表明了文档、文件或各种字节的性质和格局。它是在IETF的RFC 6838中定义的。互联网编号调配机构(IANA)负责定义所有官网的MIME类型。 MIME的构造蕴含两局部，别离是type和subtype,他们以 / 来进行宰割： type/subtype类型代表数据类型所属的个别类别，如视频或文本。子类型确定MIME类型所代表的指定类型的确切数据品种。例如，对于 MIME 类型的文本，子类型可能是 plain（纯文本）、html（HTML 源代码）或日历（对于 iCalendar/.ics）文件。 每种类型都有它本人的一套可能的子类型, 一个MIME类型必须蕴含一个类型和一个子类型。 还能够在前面加上额定的参数： type/subtype;parameter=value例如，对于主类型是text的任何MIME类型，可选的charset参数能够用来指定数据中字符的字符集。如果没有指定字符集，默认为ASCII (US-ASCII)，除非被用户代理的设置笼罩。要指定UTF-8文本文件，则应用MIME类型text/plain;charset=UTF-8。 MIME类型不辨别大小写，但传统上用小写，但参数值除外，因为参数值的大小写可能有或没有特定的意义。 MIME有两中类型，别离是discrete 和multipart。 离散类型是代表繁多文件或媒介的类型，如繁多文本或音乐文件，或繁多视频。 多局部类型是指由多个组件组成的文件，每个组件都有本人独立的MIME类型；或者，指封装在一个事务中一起发送的多个文件。例如，电子邮件中多个附件就是一种多局部MIME类型。 咱们看下常见的discrete类型： application， 比方：application/octet-stream，application/pdf，application/pkcs8和application/zip等。audioList， 比方：audio/mpeg，audio/vorbis。font， 比方：font/woff，font/ttf和font/otf。image，比方：image/jpeg，image/png和image/svg+xml。model， 比方：model/3mf 和model/vml。text，比方：text/plain, text/csv 和 text/html.video，比方：video/mp4。常见的Multipart类型如下： message，比方：message/rfc822和message/partial。multipartList， 比方：multipart/form-data 和 multipart/byteranges。浏览器嗅探因为浏览器应用MIME类型，而不是文件扩展名来决定如何解决一个URL，所以Web服务器在响应的Content-Type头中发送正确的MIME类型十分重要。如果没有正确配置，浏览器很可能会误会文件的内容，网站将无奈失常运行，下载的文件也可能会被错误处理。 为了解决这个问题，或者说是更好的用户体验，很多浏览器会进行MIME内容嗅探，也就是通过解析文件的内容，来猜想MIME类型的格局。 不同的浏览器解决MIME嗅探的形式是不一样的。然而他们都可能会产生重大的安全漏洞，因为有些MIME类型是可执行类型的，歹意攻击者能够通过混同MIME嗅探算法，从而使攻击者能够进行网站运营者或用户都没有预料到的操作，如跨站脚本攻打。 如果不想浏览器端进行嗅探，能够在服务端的响应中设置 X-Content-Type-Options 头，比方： X-Content-Type-Options: nosniff这个头最早是在IE 8中反对的，不过当初所有的浏览器根本都反对这个head类型了。 客户端嗅探咱们通常须要在JS中判断浏览器是否是IE浏览器，而后做响应的解决： var isIEBrowser = false;if (window.ActiveXObject) { isIEBrowser = true;}// Or, shorter:var isIE = (window.ActiveXObject !== undefined);下面的例子就是非常简单的客户端嗅探，通过判断window是否有ActiveXObject 这个属性来确定这个浏览器是否是IE浏览器。 本文已收录于 http://www.flydean.com/content-sniffing/最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！ ...

上篇链接:2021年，用更古代的办法应用PGP（上）2021年，用更古代的办法应用PGP（中） PGP 公钥的 公布 与 替换探讨公钥平安替换的中文文章比拟少，而这一环是整个加密体系的重中之重。 大部分的PGP教程最初一步就是让小白用户将公钥上传，这是十分过期，且不负责任的，所以这里来具体介绍下PGP 公钥的 公布 与 替换。 准则首先明确一点： 上传公钥到 公钥服务器 不是必要的，甚至是危险的。 如果你是老手，请不要公布你的公钥到 公钥服务器。 引子通过前文，你曾经相熟了gpg的本地应用， 并且生成了本人的PGP 密钥对。 设想一下， 如果你生存在1980年代， 想和远方的敌人加密通信，须要先替换彼此的公钥，又没有一个对立的可信的认证机构，这时会有什么问题？ 当面替换吗？当然是个方法，然而置信你不会想要将下列 这么长的公钥缮写到纸上，而后开车送到敌人那里，再让敌人照着这个输出他的电脑。如果两头有变动，须要反复以上过程n次。 那么还有其余方法吗？ 那个时代还没有line、wechat这类即时通讯软件，而邮件提供商默认是不牢靠的，不然也不会有PGP的诞生。 并且彼时https还未呈现，用邮件替换PGP替换公钥显然不太平安。 你们单方都须要便捷地替换公玥， 并且确认彼此失去的公钥的确是未经篡改过的，真实有效的，就成了一个难题，这样，公钥服务器也就跃然纸上了。 公钥服务器 KeyServer公钥服务器使得人们只须要替换他们短短的key id 或者user id就能够不便地从公钥服务器下载公钥。 历史与设计初衷第一个KeyServer 叫做 HKP（ web-based OpenPGP HTTP Keyserver Protocol） Keyserver ， 诞生在上世纪90年代，是Marc Horowitz在麻省理工学习时为了他的论文而搭建的。在此之前， 尽管不是那么平安， 然而大部分人依附电子邮件来替换公钥。 尽管服务器有了， 但开发者们放心政府会试图强制钥匙服务器运营商用政府抉择的各种证书来替换证书。 所以他们做出了一个决定：公钥服务器永远不会删除信息。公钥服务器能够为现有的证书增加信息（比方能够revoke/sign或者调整expire工夫），但永远永远永远不会删除证书或证书的信息。 为了达到这个指标，他们开始运行一个分布式的国内公钥服务器网络，这就是当初的KeyServer。世界各地的公钥服务器会定期互相通信，同步，比拟目录。如果政府强制公钥服务器运营商删除或批改证书，那么在比拟步骤中就会被发现。完好的公钥服务器会用完整钥匙服务器目录中的内容更新本人。 任何货色都不会被删除，听起来很美妙，也是解决政府审查问题的一个简略而无效的方法，可是正是这个准则起初给KeyServer带来了无穷无尽的问题。 信赖网络 (Web of Trust)好了，当初咱们有了一个能够不便地上传和下载公钥的中央， 这样是不是就高枕无忧了呢？ 对于KeyServer 来说，任何人都能够上传公钥并宣称本人是Linus, 是Zuckerberg,或是任何其他人，而KeyServer并不会去验证你是否是你所宣称的人（因为KeyServer原本就没有一个中心化的运营者）。 如果你有一些密码学的根底， 那么就会晓得， PGP协定依附的非对称加密算法， 最软弱的点就在于公钥的替换这一步。公钥替换时最容易收到中间人攻打，你肯定要确定你接管到的公钥的确是你想交换的人的，由此TSL引入了CA证书认证体系，由一个可信的权威第三方来认证并颁发证书来解决身份的认证问题。 （具体可参见https系列没那么浅地谈谈HTTP与HTTPS）。 “信赖一个权威的第三方” 对于最后的极具备hack精力的开发者们来说， 显然是无奈承受的。 ...

摘要：随着互联网明码泄露事件频发，越来越多的产品开始反对多因子认证（MFA），TOTP则是MFA畛域里最广泛的一种实现形式，本文介绍TOTP的原理和华为云的实践经验。原理TOTP（Time-Based One-Time Password）算法是基于工夫的一次性明码算法，依据预共享的密钥与以后工夫计算一次性明码。它已被互联网工程工作组接收为RFC 6238规范，成为被动凋谢认证的基石，并被用于泛滥多因子认证零碎当中。 TOTP其实并不是一种全新的算法，能够看成是HOTP（HMAC-Based One-Tme Password）算法的一个具体化的场景。HOTP的算法能够在RFC 4226看到详细描述，所以相比HOTP算法，TOTP的RFC文档看起来十分简洁。 下面是HOTP算法的公式，参数K示意共享密钥，参数C示意计数器counter。 TOTP算法实际上是以工夫变量作为参数C的HOTP算法，所以TOTP算法的公式应该是 参数K依然示意共享密钥，而参数T示意工夫变量。 工夫变量TTOTP的外围和实际计划也是围绕工夫变量T，但T不是简略的工夫戳， X示意步长，默认是30秒，T0示意UTC工夫的起始工夫戳，即1970年一月一日，Floor函数向下取整。T必须是一个大于32bit的整型，能力反对到2038年当前。例如当X=30时，59对应的T为1，60对应的T为2。 TOTP在MFA上的利用MFA（Multi-Factor Authentication），多因子认证，是计算机系统中一种进行身份认证的办法，用户须要通过两种或两种以上的认证伎俩的校验能力进入零碎，拜访资源。 开明MFA个别都须要先在登录认证零碎中将用户的身份和用户的物理设施进行绑定关联，在登录过程中，除了输出明码（用户晓得的），还须要输出用户的物理设施（用户持有的）上显示的拜访码（passcode）来实现整个身份验证。阐明：不是所有的MFA验证过程都须要用户被动输出拜访码。 上图示意的过程即MFA的通用流程，例如咱们应用网银进行转账就须要拿出在银行窗口开户时银行提供的一个U盾，按下按钮，U盾上即显示一串数字，输出这次数字到网银软件上能力实现转账。 但上图的MFA流程存在一个工程难题，即第4步中认证零碎后端还须要向MFA设施（或MFA设施的后盾零碎）进行一次验证，这个验证过程限度了MFA的利用场景，运行在企业数据中心的认证服务器个别不被容许拜访公网，即便拜访公网也会因为网络时延导致登录体验变差，TOTP算法的利用很好的解决了这个难题。 应用TOTP算法，只有客户端（证实方）和服务端（校验方）放弃时钟统一，且单方事后设置好一个共享密钥的前提下，在同一个工夫片段内算进去的值是一样的。正是基于这样的原理，在认证零碎中先将用户身份和该共享密钥绑定，再将共享密钥置入物理设施，在认证过程中，物理设施和认证零碎各自通过TOTP算法依据共享密钥和工夫戳计算出拜访码，只有拜访码比照统一就能证实用户持有该物理设施，整个认证过程中物理设施和认证零碎不须要有交互，非常灵活。 基于TOTP算法的设施，能够分为虚构（软件）MFA和硬件MFA。 虚构MFA虚构MFA即通过软件来模仿硬件MFA设施，在手机上安装一个反对TOTP协定的APP，例如Google Authenticator, Microsoft Authenticator，华为云APP也同样反对规范的TOTP协定。虚构MFA通过扫码二维码图片或者手工输出的形式置入校验方生成的共享密钥，并且能够同时关联多个校验方，十分不便实用。 硬件MFA下图中是一种信用卡形态的硬件MFA，能够放到钱包里，在须要时按下卡片上的按钮即可显示六位数字，十分便携。 平安思考1.哈希算法TOTP算法的强度取决于背地的HOTP算法，但HOTP的哈希函数是HMAC-SHA1，并不是我司举荐的平安算法。TOTP算法在具体实现中也能够应用HMAC-SHA256或HMAC-SHA512，但应用HMAC-SHA1依然是最通用，兼容性最好的实现，Google Authenticator就是应用HMAC-SHA1。 2.密钥随机性对TOTP算法最可能的攻打伎俩就是暴力破解，因而共享密钥必须是密码学平安的密钥，足够随机。密钥长度应该和哈希算法的长度尽量匹配。 另外，校验方必须将密钥寄存在平安的区域，应用加密形式保留，避免泄露，只有在须要验证OTP的时候才解密。同时还须要限度最小权限，只有校验方本身能力拿到密钥。 3.通信安全证实方和校验方应该应用平安的通道通信，例如SSL/TLS。 4.防暴力破解个别TOTP用于MFA时，校验方只会要求输出6位数字，很容易被暴力破解，在工程实际中能够当第二因子的尝试失败达到肯定次数后锁定客户端。 5.放弃一次性TOTP算法在同一个工夫片段（例如，30s）内的输入都是一样的，如果同一个TOTP验证曾经胜利验证过一次，该验证码的第二次尝试应该被回绝，这样能力保障OTP“一次性”的根本性质。 6.工夫片段工夫片段越长，被破解的危险就越高，但思考到证实方须要人工输出验证码，应该留下足够的操作工夫。举荐应用30秒作为默认工夫片段，在平安和易用性之间达到一个均衡。 可用性思考1.“后向兼容”因为证实方和校验方都是基于工夫来计算OTP，如果证实方在一个工夫片段的最初时刻发送OTP，在申请达到校验方时，曾经进入下一个工夫片段，如果校验方应用以后工夫来计算OTP，必定会匹配失败，这样会导致肯定的失败率，影响可用性。 校验方应该不仅仅以接管申请的工夫，还应该用上一个工夫片段来计算TOTP，加强容错性。不过，容错窗口越长，被攻打危险越高，“后向兼容”个别举荐不超过一个工夫片段。 2.反对校准证实方和校验方的时钟可能不完全一致，特地是很长一段时间没有进行过TOTP认证，时钟偏移导致匹配失败。校验方的认证零碎能够提供一种校准（re-sync）的能力，让证实方输出TOTP验证码，校验方往前计算两个工夫片段（60s），往后计算一个工夫片段（29s），通过匹配后果记录证实方的时钟的偏差值，实现时钟校准。在证实方当前发动验证时，校验方间接应用偏差值计算TOTP。但如果厂商曾经反对足够的“后向兼容”，校准不肯定须要反对。 点击关注，第一工夫理解华为云陈腐技术~

摘要：很多平安标准及平安文章中都提到一条规定：先加密后签名是不平安的，该当先签名后加密。这条规定背地的原理是什么？先加密后签名肯定不平安吗？本文为您一一解答。先签名后加密是指先对音讯进行签名，而后对音讯的签名值和音讯一起进行加密。如果采纳先加密后签名的形式，接管方只能晓得该音讯是由签名者发送过去的，但并不能确定签名者是否是该音讯的创建者。比方在发送一个认证凭据时采纳先加密后签名的形式，音讯在发送过程中就有可能被第三方截获并将认证凭据密文的签名值批改为本人的签名，而后发送给接管方。第三方就有可能在不需晓得认证凭据的状况下通过这种形式来通过认证获取权限。 采纳先签名后加密形式能够防止这类问题的产生，因为只有在晓得音讯明文的状况下能力对其进行签名。 尽管不同的标准形容有差别，但外围观点都是“先签名后加密”。然而这条标准的实用场景是什么呢，“先加密后签名”肯定不平安吗？须要深挖一下。 如果应用“先加密后签名”，则音讯发送方Alice和音讯接管方Bob的处理过程如下图： Alice发送的明文音讯先通过Alice私钥签名，再将音讯明文和音讯签名一起应用Bob的公钥加密，密文通过网络传输到Bob。因为Bob应用私钥解密还原出音讯明文和签名，而私钥只有Bob持有，这能保障音讯明文不会泄露给第三方Eve，而后Bob应用Alice的公钥验证音讯明文和签名是否统一，因为Alice的签名只有Alice的公钥能力验证，这能保障音讯肯定来自Alice，不可抵赖，且没有被第三方Mallory篡改。在拿不到音讯明文的状况下，无奈计算出音讯签名，而还原音讯明文又必须应用Bob的私钥，这样就能防止网络传输过程中的中间人进行篡改攻打。 如果“先加密后签名”，会存在什么样的攻打危险呢，先看下“先加密后签名”的解决流程： 音讯明文应用Bob的公钥加密，不可能泄露给第三方，签名也有了，能够防篡改，不认真看的话，仿佛没什么问题。持续看上面这张图： 如果存在一个中间人Mallory能够拦挡Alice和Bob的音讯，在不篡改音讯明文和密文的状况下，应用Mallory的私钥对音讯密文进行签名，并替换Alice原始的签名，最初篡改后的音讯传输给接管方Bob，Bob依然能够胜利解密明文，同时用Mallory的公钥胜利验证签名，最终这条音讯会被Bob认为是Mallory发送的非法音讯。 “先加密后签名”肯定不平安吗从下面的演示来看，“先加密后签名”仿佛肯定不平安，是这样吗？中间人Mallory针对“先加密后签名”进行替换签名攻打得手的前提条件： 1、 接管方Bob依据签名内容中的证书ID找到对应的Mallory公钥来验证签名。 2、 接管方Bob仅应用公钥验签来辨认发送方的身份。 只有突破下面的任意一个前提，“先加密后签名”也是平安的： 1、 Bob应用固定的公钥来验证签名，而不是依据签名内容来找对应公钥，或者不应用多个公钥尝试验签。即Mallory替换签名后，Bob依然用Alice的公钥验证签名，必定能发现申请被篡改。 2、 Bob应用公钥+应用层属性一起辨认发送方的身份，假如Alice在音讯明文中携带本人的用户ID，Bob验证公钥和用户ID是否匹配，即便Mallory替换签名也无奈攻打。 所以“先加密后签名”是不是平安，还要看业务利用是怎么设计的，不能相对的认定为不平安。 本文分享自华为云社区《“先签名后加密”的思考》，原文作者：卡农。点击关注，第一工夫理解华为云陈腐技术~

在前面的一些文章中，我们介绍了如何在云上安全的存放配置数据，但是上面的方法都是有代码侵入性的，也就是说需要修改应用程序，本文会讲解如何使用 confd+ACM 在不修改代码的情况下动态修改应用所需的配置，并且可以重新启动应用加载最新的配置。这样做可以在无代码侵入的情况下加强应用程序的安全性和运维效率： 安全性：应用程序的数据可能是敏感数据，ACM 具有健壮的访问控制机制，可以对敏感数据进行加密来安全的保存密码、API密钥、证书等敏感信息;运维效率：当需要修改应用的某些配置内容时，如果只有一两台机器可以手工操作，但是当涉及几十上百台数量的时候，confd+ACM可以通过配置的发布批量进行配置修改和重启操作;无代码侵入：通过confd+ACM的组合可以做到无需修改应用代码即可达到让应用配置动态生效的效果 下面以应用的数据库配置为例讲解如何使用confd+ACM安全管理应用配置 准备工作在操作本文的示例之前需要配置好开通ACM和对confd的使用有基本概念，ACM的开通及其基本使用可以参考：这里confd的基本使用可以参考：这里 创建confd配置文件创建confd所需的toml格式配置文件 vim /etc/confd/conf.d/myapp.toml指定模版文件，ACM中的加密配置需要以/cipher-开头check_cmd用于检验配置的正确性，防止错误配置导致应用加载失败reload_cmd用于重启应用或者让应用动态加载配置 [template]src = "jdbc.properties.tmpl"dest = "/tmp/jdbc.properties"keys = ["/cipher-myapp/database/jdbc",]#check_cmd = "check config is correct"reload_cmd = "restart app"创建模版文件vim /etc/confd/templates/jdbc.properties.tmplgetv从ACM中获取对应dataId的配置:/cipher-myapp/database/jdbc对应的dataId为cipher-myapp.database.jdbcconfd基于kms会自动对/cipher-开头的配置进行解密 {{$data := json (getv "/cipher-myapp/database/jdbc")}}jdbc.url={{$data.url}}jdbc.username={{$data.username}}jdbc.password={{$data.password}}在ACM上创建所需的配置文件创建dataId为cipher-myapp.database.jdbc的配置文件，group使用默认的DEFAULT_GROUP即可，配置内容为 {"url":"jdbc:mysql://localhost:3306/dbName","username":"testuser","password":"testpassword"} 启动confd和官网文档不同的是，要支持解密功能，需要设置confd的-openKMS开关，并且设置kms服务的regionId，这个信息可以从示例代码中获得 confd -backend nacos -endpoint {endpoint}:8080 -namespace {namespace} -accessKey {accessKey} -secretKey {secretKey} -openKMS true -regionId {regionId} -watch 生成配置文件查看生成的/tmp/jdbc.properties配置文件，如果生成了该文件，并且文件内容如下则说明整个流程运行正常 jdbc.url=jdbc:mysql://localhost:3306/dbNamejdbc.username=testuserjdbc.password=testpassword变更ACM配置内容当需要修改数据库的连接串的时候，直接在ACM上修改cipher-myapp.database.jdbc配置，confd会重新生成数据库配置文件，并让应用加载最新配置。当然在实际生产环境中，可以使用ACM的Beta功能对几台机器先进行灰度发布，检验没问题再继续全量发布 本文演示了如何使用confd+ACM安全管理敏感数据，ACM安全配置更多信息还可以参考：这里 本文作者：风卿，Nacos 社区 Committer 本文作者：中间件小哥阅读原文 本文为云栖社区原创内容，未经允许不得转载。

最近需要在nodejs上加密jwt,C#端解密jwt得到用户信息 class JwtService extends Service { encrypt(content) { const secretkey = this.app.config.jwt.key // 唯一（公共）秘钥 const cipher = crypto.createCipher('aes-128-ecb', secretkey) // 使用aes128加密 let enc = cipher.update(content, 'utf8', 'hex') // 编码方式从utf-8转为hex; enc += cipher.final('hex')// 编码方式转为hex; return enc }}却发现C#端怎么也解密不了，一直报错，改了一整天，后来终于发现，nodejs端加密用的key其实在使用之前已经使用md5加密了一次，服务端如果需要使用这个key解密，则需要也同样使用MD5加密 public static string AesDecrypt(string content, string key) { // nodejs aes加密默认的key使用了md5加密，所以C#解密的key也要默认使用md5 MD5 md5 = new MD5CryptoServiceProvider(); byte[] output = Encoding.UTF8.GetBytes(key); byte[] keyArray = md5.ComputeHash(output); byte[] toEncryptArray = HexStringToBinary(content); RijndaelManaged des = new RijndaelManaged(); des.Key = keyArray; des.Mode = CipherMode.ECB; des.Padding = PaddingMode.PKCS7; ICryptoTransform cTransform = des.CreateDecryptor(); byte[] resultArray = cTransform.TransformFinalBlock(toEncryptArray, 0, toEncryptArray.Length); return Encoding.UTF8.GetString(resultArray); }代码使用了一个函数把16进制转成字节数组 ...

一、概述1.1大致目的进一步了解HTTP和HTTPS了解对称加密和非对称加密的工作方式对HTTPS的加密有一个大概的了解对证书有一个初步的了解1.2加密方式在学习HTTPS加密方式之前，有必要了解几种常见的加密方式，如： 对称加密非对称加密二、对称加密2.1定义需要对加密和解密使用相同密钥的加密算法。所谓对称，就是采用这种加密方法的双方使用方式用同样的密钥进行加密和解密。密钥是控制加密及解密过程的指令。算法是一组规则，规定如何进行加密和解密。注意：对称加密也叫密钥加密 2.2密钥的形式采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。 2.3优缺点优点：对称加密算法的优点是算法公开、计算量小、加密速度快、加密效率高。缺点：对称加密，密钥管理的安全性很低，因为加密和解密都使用同一个密钥，在密钥的发送过程中，密钥可能被第三方截取，导致第三方也可以破解密文。 2.4具体实现在每次发送真实数据之前，服务器先生成一把密钥，然后先把密钥传输给客户端。之后服务器给客户端发送真实数据的时候，会用这把密钥对数据进行加密，客户端收到加密数据之后，用刚才收到的密钥进行解密。 2.5图解我们以客户端发送请求给服务器为例：对称加密在第一部和第二部上均可被第三者拦截（实时是第二步一般均可以被拦截，但是能否解密还是要看第一步是否把密钥拦截下来）因为，对称加密的解密钥匙和加密钥匙均是同一把。 三、非对称加密3.1定义非对称加密算法需要两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。如果用公钥对数据进行加密，只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。 3.2密钥的形式公钥与私钥是一对。传输双方均有自己的一对密钥（也就是双方每方均有：公、私密钥一把，双方加起来共4把） 例子:传输双方比如是甲乙双方，甲方有配对的公、私密钥一对，且公钥负责加密，私钥负责解对应的公钥加的密。乙方同理。 3.3优缺点非对称密钥的算法强度复杂（是优点也是缺点），安全性依赖于算法与密钥。优点：安全性较高，比对称密钥安全性高很多。 非对称加密算法的保密性比较好，它消除了最终用户交换密钥的需要。缺点：由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。 3.4具体实现1.客户端要向服务器发送信息，客户端和服务器都要产生一对用于加密和解密的公钥和私钥。2.客户端的私钥保密，客户端的公钥告诉服务器；服务器的私钥保密，服务器的公钥告诉客户端。3.客户端要给服务器发送信息时，客户端用服务器的公钥加密信息，因为服务器的公钥是公开的，客户端可以得到。4.客户端将这个消息发给服务器（已经用服务器的公钥加密消息）。5.服务器收到这个消息后，服务器用自己的私钥解密客户端的消息。其他所有收到这个报文的人都无法解密，因为只有服务器才有服务器的私钥。 3.5图解 四、HTTPS采用的加密HTTPS采用的是处理信息的方式是：结合对称加密+非对称加密这两种方式，我们可以用非对称加密的方式来传输对称加密过程中的密钥，之后我们就可以采取对称加密的方式来传输数据了。具体是这样子的： 服务器用明文的方式给客户端发送自己的公钥，客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，之后再把密钥传输给服务器，服务器收到之后进行解密，最后服务器就可以安全得到这把密钥了，而客户端也有同样一把密钥，他们就可以进行对称加密了。 五、证书5.1非对称加密的不足事实上，在没有引入证书之前，非对称加密也并非传输安全的，在此举个例子： 服务器以明文的方式给客户端传输公钥的时候，中间人截取了这把属于服务器的公钥，并且把中间人自己的公钥冒充服务器的公钥传输给了客户端。 之后客户端就会用中间人的公钥来加密自己生成的密钥。然后把被加密的密钥传输给服务器，这个时候中间人又把密钥给截取了，中间人用自己的私钥对这把被加密的密钥进行解密，解密后中间人就可以获得这把密钥了。 最后中间人再对这把密钥用刚才服务器的公钥进行加密，再发给服务器。 毫无疑问，在这个过程中，中间人获取了对称加密中的密钥，在之后服务器和客户端的对称加密传输中，这些加密的数据对中间人来说，和明文没啥区别。 5.2证书的引入非对称性加密之所以不安全，是应为客户端不知道，这把公钥是不是服务器的。因此，我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的。解决这个问题的方式就是使用数字证书，具体是这样的： 1、我们需要找到一个第三方机构，它是一个拥有公信力、大家都认可的认证中心，那就是数字证书认证机构(简称CA)。2、服务器在给客户端传输公钥的过程中，会把公钥以及服务器的个人信息通过Hash算法生成信息摘要。为了防止信息摘要被人调换，客户端还会用CA提供的私钥对信息摘要进行加密来形成数字签名。并且，最后还会把原来没Hash算法之前的个人信息以及公钥和数字签名合并在一起，形成数字证书。3、当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则就不是。这样，就可以保证服务器的公钥安全着交给客户端了。 5.3浏览器内置常用证书一个重要的问题是，如何安全转交认证机构的公钥是一件很困难的事，因此，大多数浏览器开发商发布版本时，会事先植入常用认证机关的公钥。我们可以Google Chrome为例：打开浏览器的设置选项，选择高级，可以看到隐私设置和安全性下面的一些设置，其中管理证书就可以看到谷歌浏览器一些内置证书，如图： 5.4图解下图选自图解HTTP： 5.5分析实例我们分析下下面的三种情况 1、网站是http协议的：可以看到是不安全的。2、 网站是完全的HTTPS加密的:可以看到Google网站的HTTPS前面是有一把小锁的，这表示，这个网站的连接是安全的，并且点击小锁可以看到证书信息。3、 网站前带HTTPS但是不是完全安全的：注意第三点和第一点的表达：连接不安全和连接并非完全安全这是因为：站点还有http资源，需要把所有链接换成https才可以带锁。 参考资料 ：图解HTTP百度百科http加密那点事

云数据库 MongoDB 版 基于飞天分布式系统和高性能存储，提供三节点副本集的高可用架构，容灾切换，故障迁移完全透明化。并提供专业的数据库在线扩容、备份回滚、性能优化等解决方案。 了解更多 MongoDB World 2019 上发布新版本 MongoDB 4.2 Beta，包含多项数据库新特性，本文尝试从技术角度解读。 Full Text SearchMongoDB 4.2 之前，全文搜索（Full Text Search）的能力是靠 Text Index 来支持的，在 MongoDB-4.2 里，MongoDB 直接与 Lucene 等引擎整合，在 Atlas 服务里提供全文建索的能力。 MongoDB FTS 原理用户可以在 Atlas 上，对集合开启全文索引，后台会开起 Lucene 索引引擎（索引引擎、查询引擎均可配置），对存量数据建立索引。对于开启全文建索的集合，新写入到 MongoDB 的数据， 后台的服务会通过 Change Stream 的方式订阅，并更新到 Lucene 索引引擎里。索引的查询直接以 MongoDB Query 的方式提供，Mongod 收到请求会把请求转发到 Lucene 引擎，收到建索结果后回复给客户端。Full Text Search 示例下面是一个 Full Text Search 使用的简单示例，整个使用体验非常简单，除了需要在 Atlas 控制台上建索引，其他跟正常使用 MongoDB 毫无差别，随着这块能力的完善，能覆盖很多 Elastic Search 的场景。 Step1: 准备数据 ...

Grails3 Spring Secuirty自定义加密方式应用场景公司老项目使用grails2.0+版本，他的加密方式为encodeAsSHA256，数据是通过导入实现，要兼容以前数据加密方式，使以前使用老项目的用户也能用原先的密码登录。首先，我做了一下测试def test() { map.password1 = "123456".encodeAsSHA256() map.password2 = springSecurityService.encodePassword("123456") render map as JSON}结果发现他们是两种不同的加密方式接下来只能通过重写父类方法实现统一加密第一步：自定义一个类，我习惯在src/main/goovy下创建CustomPasswordEncoder.groovy类，也可以创建java类package com.encoderimport org.springframework.security.authentication.encoding.MessageDigestPasswordEncoderimport org.springframework.security.authentication.encoding.PasswordEncoderUtilsimport org.springframework.security.crypto.codec.Heximport org.springframework.util.Assertimport java.security.MessageDigest/** * 自定义加密覆盖默认加密方式 * 项目spring-security版本为3.1.0，本可以重新BaseDigestPasswordEncoder类 * 但是本人看BaseDigestPasswordEncoder类被标记为删除了，所以通过重写MessageDigestPasswordEncoder类方法实现 */class CustomPasswordEncoder extends MessageDigestPasswordEncoder { // 默认为MD5 private String algorithm = "MD5"; // 加密次数（提高安全） private int iterations = 1; CustomPasswordEncoder() { // 当前类默认构造器，因为父类没有空构造器，所以这里必须调用父类有参构造，这里传入参数必须是父类存在的加密规则，否则报错 super("SHA-256") } CustomPasswordEncoder(String algorithm) { super(algorithm, false); this.algorithm = algorithm } CustomPasswordEncoder(String algorithm, boolean encodeHashAsBase64) throws IllegalArgumentException { super() setEncodeHashAsBase64(encodeHashAsBase64); this.algorithm = algorithm; getMessageDigest(); } @Override String encodePassword(String rawPass, Object salt) { String saltedPass = this.mergePasswordAndSalt(rawPass, salt, false) MessageDigest messageDigest = this.getMessageDigest() byte[] digest = messageDigest.digest(saltedPass.getBytes("UTF-8")) for (int i = 1; i < iterations; i++) { digest = messageDigest.digest(digest); } // 先判断是否启用base64 if (this.getEncodeHashAsBase64()) { return new String(Base64.encodeAsBase64(digest)) // 判断是否为自定义的SHA-256-1(框架自定加密方式，非spring security框架，这里指的是grails自带的加密) } else if ("SHA-256-1".equalsIgnoreCase(algorithm)) { return rawPass.encodeAsSHA256() } else { // 使用用户配置的其他加密方式 return new String(Hex.encode(digest)) } } @Override boolean isPasswordValid(String encPass, String rawPass, Object salt) { String pass1 = "" + encPass String pass2 = encodePassword(rawPass, salt) return PasswordEncoderUtils.equals(pass1, pass2) } String getAlgorithm() { return algorithm; } void setIterations(int iterations) { Assert.isTrue(iterations > 0, "Iterations value must be greater than zero"); this.iterations = iterations; }}第二步：在grails-app/conf/spring/resources.groovy中注册一下beanbeans = { // 自定义密码 passwordEncoder(com.encoder.CustomPasswordEncoder) { encodeHashAsBase64 = false // 若为true，则以base64方式加密 }}第三步：在grails-app/conf/application.groovy中添加配置// 原框架加密方式，有SHA-256、bcrypt、MD5、pbkdf2，默认为bcrypt// 自定义加密默认为MD5，这里SHA-256-1为自定义加密，还可以用SHA-256等grails.plugin.springsecurity.password.algoritham = 'SHA-256-1'到这里配置就已经完成了，启动测试注意：项目中用到domain.save(failOnError: true)的有时需要修改为domain.save(flush: true)，我测试密码修改时，failOnError: true没有修改成功。参考 ...

加密服务（阿里云数据加密服务）是云上的加密解决方案。服务底层使用经国家密码管理局检测认证的硬件密码机，通过虚拟化技术，帮助用户满足数据安全方面的监管合规要求，保护云上业务数据的隐私性要求。借助加密服务，用户能够对密钥进行安全可靠的管理，也能使用多种加密算法来对数据进行可靠的加解密运算。 阿里云加密服务的详细内容：阿里云加密服务使用教程 **功能描述：数据加密**数据的英文企业的核心资产，每个企业都有自己的核心敏感数据。包括企业自身的敏感数据，如合同，交易，流水等，企业用户的敏感数据，如身份证，银行卡等。这些数据都需要加密服务来保护不会被他人获取。 加密算法支持全面支持国产算法以及部分国际通用密码算法，满足用户各种加密算法需求。对称密码算法：支持SM1，SM4，DES，3DES，AES 非对称密码算法：支持SM2，RSA（1024至2048年）摘要算法：支持SM3，SHA1，SHA256，SHA384 金融行业支持符合中国人民银行标准和规范的金融行业定制加密需求，全面支持金融支付领域的加解密需求1.2.PIN码的产生/加密/转加密/验证等2.ARQC的生成/验证，脚本加密，脚本MAC等3.MAC1计算及验证，MAC2计算及验证，TAC验证等4.外部认证，更新密钥，内部认证等5.敏感数据加密，转加密，报文MAC计算及验证等6.CVV / CVN产生及校验，PVV / PVN的产生及校验 阿里云加密服务的详细内容：阿里云加密服务使用教程

一. 引言今天使用git clone的时候由于没有配置ssh 但是使用了ssh的clone命令，出了点问题。仔细研究了一下，还是挺有意思点，希望通过阅读下面的内容能给大家带来一些收获。 二. git clone的两种方式.git clone分为两种方式，一种是通过ssh，还有一种是通过http(s)。 1. ssh 在clone的时候可以选择SSH，首先在命令行输入 ssh-keygen -t rsa -b 40996 -C “邮箱” ，一路点击确定，在本地生成.ssh文件，里面有id_rsa(私钥) id_rsa.pub(公钥)，将公钥上传到github上就可以直接免密与github进行文件传输了 // 在本地存在.ssh文件后// 终端输入 $ cd ~/.ssh/ $ cat id_rsa.pub $ ssh-rsa xxxxxxxxxxxxxxxxxxx yourAccount// 复制上面出现的内容在gitlab(github)-->个人账户-->setting-->ssh 将刚复制的公钥粘贴 此时就完成了ssh设置，再clone就是免密的啦。 `这里要提心一下，这时候clone的格式一定是 3.git clone git@xxxxxxxxxx` 2. HTTPHTTP的方式比较简单，就是 git clone 给定的url，然后输入自己在gitlab(github)上相应的账号就行了。 3. ssh与HTTP方式的比较想要比较他们之间的优缺点，首先要搞清楚为什么会这么设计。我个人认为，项目一般分为两类，一类是团队（个人）的项目，一类是开源的项目。团队（个人）项目，具有私有性。同时拉或者推为了方便都应该不需要验证。这就需要保证数据在传输中的私有与可靠。所以使用ssh这种RSA加密的方式。开源项目，具备公有特性。一方面如果每个参与者的数据的拉取都进行加密解密的话，代价将会非常大。另外一个方面，对于众多提交者，代码应该由管理者去审核是否merge,同时代码也没有必要所以没有必要保持传输过场中的私有可靠。所以可以采用HTTP明文传输或者HTTPS也可以。 三. 加密上面介绍了git clone 的两种方式，探讨了一下引入这两种方式的原因，同时引入了加密这个该概念。 在密码学中，加密（英语：Encryption）是将明文信息改变为难以读取的密文内容，使之不可读的过程。只有拥有解密方法的对象，经由解密过程，才能将密文还原为正常可读的内容。具体在前端中你至少要明白下面几个概念：公钥、私钥、RSA、数字证书、https与http的关系、TLS与SSL我将在本篇文章和下篇文章为大家一一道来 1. 对称加密对称加密很简单，就是明文经过密钥转化成密文，倘若我知道密钥和密文，我也可以推出明文，典型的像是摩尔斯码。所以在谍战片中，我们经常看到特务找密码本，就是因为有了密码本就可以破译密文了。 2. 非对称加密（RSA）在对称加密中，由于是直接传递的密钥，密钥容易被人窃取导致信息泄漏， 人们认识到，加密和解密可以使用不同的规则，只要这两种规则之间存在某种对应关系即可，这样就避免了直接传递密钥。这种加密方式就叫做非堆成加密。1977年，三位数学家Rivest、Shamir 和 Adleman 设计了一种算法，可以实现非对称加密。这种算法用他们三个人的名字命名，叫做RSA算法。从那时直到现在，RSA算法一直是最广为使用的"非对称加密算法"。毫不夸张地说，只要有计算机网络的地方，就有RSA算法。 在RSA加密算法中，公钥用于对数据进行加密，私钥用于对数据进行解密 在RSA签名算法中，私钥用于对数据进行签名，公钥用于对签名进行验证。3. sshssh也是一种典型的非对称加密的方式，本机产生id_rsa(私钥) id_rsa.pub(公钥)，将公钥上传到github上。pull的时候公钥用于对数据进行加密，私钥用于对数据进行解密，push的时候私钥用于对数据进行签名，公钥用于对签名进行验证。 4. 拓展这里再介绍一个部署项目的方法，比如我们开发项目，把项目托管到gitlab上，然后当我们上线的时候将本地文件上传到服务器上。说实话这一步还是比较麻烦的。我们能不能让gitlab和我们线上服务器通过ssh连接，当gitlab代码更新到最新版本的时候，线上我只需要运行git pull 就自动完成文件的拉取和更新了。 ...

摘要： 如何定义下一代存储标准？在阿里云智能存储产品资深总监Alex Chen看来，其本质必须具备以下四个特性：安全稳定、优化、无缝上云、智能。数字经济"乘云而上"。十年前，阿里云开始自主研发云计算操作系统飞天之路，开启了中国云时代；十年后，阿里云在中国市场份额超过2-8名总和，培育了整个中国云计算市场，数字经济在云上蓬勃发展。十年前，EMC、NetApp、IBM等国际独立存储大厂称霸市场，中国企业存储市场被国际寡头瓜分，一本万利；十年后，中国存储市场国产率超过50%，Dell EMC、NetApp、Commvault、Veritas都紧紧包围阿里云构建合作伙伴生态，云上数字经济成为了企业存储走向新的发展阶段的原动力。如果说云计算是数字经济时代发展的新范式，那么，存储作为数字化基础架构的核心，将成为支撑数字化到智能化转型升级的基石。尤其在混合云大势得道的今天，存储架构应对不同介质、技术、应用的演进升级，存储系统对云和云上应用的支撑能力，以及对海量数据的智能化分析和管理，都成为了下一代存储的核心考量标准。软件定义、分布式、融合、云资源化、两地三中心……这些技术名词几乎占据了存储热搜榜，在面向云的数字化和智能化的转型风口，未来存储之路如何发展？如何定义下一代存储标准？在阿里云智能存储产品资深总监Alex Chen看来，其本质必须具备以下四个特性：安全稳定、优化、无缝上云、智能。更安全更稳定数据是企业最重要的资产，存储是数据的载体，数据安全对存储的要求不言而喻。云环境下，数据存储是由大量数据存储节点构成分布式数据中心，通过虚拟化拓展了存储容量并提高存储和读取数据性能，让用户可以充分享受高效、稳定的存储服务。但同时，数据的加密存储、数据隔离、数据迁移、数据安全审计等环节也都考验着云存储的安全可靠性。在这点上，任何云厂商都也不例外。Alex介绍，打造更高数据安全稳定标准是阿里云始终坚持的首要目标。在安全方面，阿里云存储产品具备全面的静态数据加密能力。以对象存储（OSS）为例，提供包括KMS密钥、BYOK密钥、OSS托管密钥完成服务端数据加密和客户端线下加密等5种加密方式，也是中国首家通过Cohasset Associates审计认证，符合美国证券交易委员会（SEC）和金融业监管局（FINRA）合规要求的云厂商，已成功在海外服务国际金融行业客户，此举也标志着阿里云已实现合规方面的里程碑式建设。在稳定性方面，经过十年的技术积累和沉淀，阿里云自研飞天大规模的分布式存储引擎已经换代升级为盘古2.0；基于盘古2.0，整个阿里巴巴今天有60%-70%的流量跑在公共云上，扎实的底层存储系统支撑了十年“双11”大规模高并发洪峰考验，也为阿里云成为最佳实践的云打下良好基础。更优化不同应用需要不一样的存储架构，对IOPS、延时、吞吐的要求也自然不同，没有一个存储产品可以做到完全覆盖所有的应用场景。在阿里云的产品设计上，针对不同场景下，提供满足用户定制化需求的最优存储类型服务。在数据库和实时业务分析场景下，阿里云推出全球百万级IOPS的企业级ESSD云盘，相比于SSD云盘分别提升40倍性能和降低70%读写延时，在实际的业务场景测试下，以MySQL和PostgreSQL为例，采用ESSD云盘可获得3-4倍的TPS性能提升。此外，ESSD云盘支持不停机扩展容量、不停机提高IO读写性能上限、数据加密等高级数据服务功能，给客户在弹性、安全等方面带来了更多的技术红利。在容器共享存储、动态网站、DevOps开发测试的小文件读写场景下，阿里云推出文件存储NAS极速型规格，提供百微秒级延时，同时提供文件系统级快照，以提升数据安全性。在大数据和离线数据分析、机器学习场景下，阿里云发布全球首个云原生文件存储HDFS，无需关心和维护底层存储，降低TCO，真正解决了传统自建HDFS系统计算存储耦合的问题，使得真正实现了计算存储分离，实现存储计算分离后分别拥有享受可线性扩展的吞吐能力和免运维的快速弹性伸缩能力。在HPC、人工智能、基因生命科学场景下，阿里云发布高性能文件存储CPFS，提供针对亿级文件，提供TB/s级超高吞吐的并行文件存储服务，并与阿里云计算生态无缝对接，满足计算密集型场景应用的高性能要求。无缝上云根据IDC公开报告显示，85%的大型企业表示不会将所有数据存储一地，而是会采用更多方式且适合自己的方法，在混合云环境中实现数据在其整个生命周期中的流转。Alex认为，通过混合云IT架构无缝上云已成为企业应用的新常态，混合云存储将成为架起本地数据中心和公共云的桥梁，开启传统企业用户上云的新路径。在3月的阿里云北京峰会上，阿里云发布全新Apsara SA系列混合云存储阵列，实现了本地数据中心架构和公共云存储的无缝结合，融合了IP SAN、FC SAN、NAS和OSS多种存储协议，提供异构存储虚拟化、双活容灾、混合云协同计算、在线多控横向扩展等企业级存储特性，支持端到端数据加密，满足数据库，虚拟化，文件共享，数据分析等各类场景下企业客户对数据存储和灾备等需求。更智能如果说单纯的卖存储、安全、计算等能力是云计算的1.0时代，那么以智能化为核心的2019年，则是阿里云进入2.0时代的标志。Alex表示，阿里云存储在第一阶段完成了以弹性扩展、灵活高效、降低成本为核心的存储基础服务，在第二阶段，除了支撑集团100%业务上云外，还要帮助更多企业实现数据管理的数字化和智能化，不仅是存储，更是数据智能管理平台。针对不同业务场景，阿里云发布了智能媒体管理视频型实例，提供场景化封装数据智能分析管理，为云上文档、图片、视频提供一站式数据处理、分析、检索等智能管理体验。阿里云日志服务是面向日志类数据的智能化一站式平台，针对AIOps场景，新增面向趋势预测、异常发现、智能聚类、根因分析（推导）等4个高频场景系列函数，提升DevOps分析与诊断的效率，该功能已通过阿里巴巴“双11”实战验证。后记2018年底，阿里云正式升级为阿里云智能。3个月后的阿里云北京峰会上，阿里云首次对外公布了云的下一阶段发展定位和云到云智能的思考。在对Alex Chen的采访中，这位曾在IBM存储领域有着19年丰富经历的专家同时坦言，“安全稳定、优化、无缝上云、智能”不仅是云时代下一代存储的本质性特点，是阿里云未来几年存储创新的主方向，也将是企业存储厂商产品服务能力比拼的主赛道。2018年，阿里云已实现完整的存储基础服务，丰富的数据服务，多元的应用场景的产品布局，成功签约5家渠道代销商，并与合作伙伴在产品层面打造混合云解决方案，开拓企业级存储市场。不难预见，2019年阿里云将持续围绕下一代存储理念持续技术创新，不断拓展存储边界，深耕数据密集型细分行业，并同更多的合作伙伴一起构建企业级存储生态，这同时也意味着以阿里云为代表的云计算厂商也真真正正的进入企业级存储市场竞争格局中。而在这样的2019年，无论对于存储市场还是用户，都是好事。本文作者：株莉阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要在SQL Server安全系列专题月报分享中，我们已经分享了：如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥实现SQL Server列加密、使用混合密钥实现SQL Server列加密技术、列加密技术带来的查询性能问题以及相应解决方案、行级别安全解决方案和SQL Server 2016 dynamic data masking实现隐私数据列打码技术这六篇文章，文章详情可以参见往期月报。本期月报我们分享使用证书做数据库备份加密的最佳实践。问题引入谈及数据库安全性问题，如何预防数据库备份文件泄漏，如何防止脱库安全风险，是一个非常重要的安全防范课题。这个课题的目的是万一用户数据库备份文件泄漏，也要保证用户数据的安全。在SQL Server中，2014版本之前，业界均采用的TDE技术来实现与防范脱库行为，但是TDE的原理是需要将用户所有的数据进行加密后落盘，读取时解密。这种写入时加密，读取时解密的行为，必然会导致用户查询性能的降低和CPU使用率的上升（具体对性能和CPU影响，可以参见这片测试文章SQL Server Transparent Data Encryption (TDE) Performance Comparison）。那么，我们一个很自然的问题是：有没有一种技术，既可以保证备份文件的安全，又能够兼顾到用户查询性能和CPU资源的消耗呢？这个技术就是我们今天要介绍的数据库备份加密技术，该技术是SQL Server 2014版本首次引入，企业版本和标准版支持备份加密，Web版和Express版支持备份加密文件的还原。具体实现创建测试数据库为了测试方便，我们专门创建了测试数据库BackupEncrypted。– create test databaseIF DB_ID(‘BackupEncrypted’) IS NOT NULL DROP DATABASE BackupEncryptedGOCREATE DATABASE BackupEncryptedON PRIMARY(NAME = BackupEncrypted_data, FILENAME = N’E:\SQLDATA\DATA\BackupEncrypted_data.mdf’, SIZE = 100MB, FILEGROWTH = 10MB),FILEGROUP SampleDB_MemoryOptimized_filegroup CONTAINS MEMORY_OPTIMIZED_DATA ( NAME = BackupEncrypted_MemoryOptimized, FILENAME = N’E:\SQLDATA\DATA\BackupEncrypted_MemoryOptimized’)LOG ON ( NAME = BackupEncrypted_log, FILENAME = N’E:\SQLDATA\DATA\BackupEncrypted_log.ldf’, SIZE = 100MB, FILEGROWTH = 10MB)GO创建测试表在测试数据库下，创建一张用于测试的表testTable，并插入一条随机数据。USE [BackupEncrypted]GO– create test table and insert one recordIF OBJECT_ID(‘dbo.testTable’, ‘U’) IS NOT NULL DROP TABLE dbo.testTableGOCREATE TABLE dbo.testTable( id UNIQUEIDENTIFIER default NEWID(), parent_id UNIQUEIDENTIFIER default NEWSEQUENTIALID());GOSET NOCOUNT ON;INSERT INTO dbo.testTable DEFAULT VALUES;GOSELECT * FROM dbo.testTable ORDER BY id;该条数据内容如下截图：创建Master Key和证书创建Master Key和证书，用于加密数据库备份文件。USE masterGO– If the master key is not available, create it. IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE name LIKE ‘%MS_DatabaseMasterKey%’) BEGIN CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘MasterKey*’; END GOUSE masterGO– create certificateCREATE CERTIFICATE MasterCert_BackupEncryptedAUTHORIZATION dboWITH SUBJECT = ‘Backup encryption master certificate’,START_DATE = ‘02/10/2017’,EXPIRY_DATE = ‘12/30/9999’GO备份证书首先，将证书和证书密钥文件备份到本地，最好它们脱机保存到第三方主机，以免主机意外宕机，导致证书文件丢失，从而造成已加密的备份文件无法还原的悲剧。USE masterGOEXEC sys.xp_create_subdir ‘C:\Tmp’– then backup it up to local pathBACKUP CERTIFICATE MasterCert_BackupEncrypted TO FILE = ‘C:\Tmp\MasterCert_BackupEncrypted.cer’WITH PRIVATE KEY ( FILE = ‘C:\Tmp\MasterCert_BackupEncrypted.key’, ENCRYPTION BY PASSWORD = ‘aa11@@AA’);加密完全备份创建完Master Key和证书文件后，我们就可以做数据库完全备份加密操作。USE master;GO– do full backup database with encryptionBACKUP DATABASE [BackupEncrypted] TO DISK = N’C:\Tmp\BackupEncrypted_FULL.bak’ WITH COMPRESSION, ENCRYPTION ( ALGORITHM = AES_256, SERVER CERTIFICATE = MasterCert_BackupEncrypted), STATS = 10;GO加密差异备份数据库差异备份加密，备份操作前，我们插入一条数据，以供后续的测试数据校验。USE [BackupEncrypted]GO– insert another recordSET NOCOUNT ON;INSERT INTO dbo.testTable DEFAULT VALUES;GOSELECT * FROM dbo.testTable ORDER BY id;USE master;GO–Differential backup with encryptionBACKUP DATABASE [BackupEncrypted]TO DISK = N’C:\Tmp\BackupEncrypted_DIFF.bak’WITH CONTINUE_AFTER_ERROR,ENCRYPTION ( ALGORITHM = AES_256, SERVER CERTIFICATE = MasterCert_BackupEncrypted), STATS = 10, DIFFERENTIAL;GO差异备份操作前，校验表中的两条数据如下图所示：加密日志备份数据库事物日志备份加密，备份前，我们照样插入一条数据，以供后续测试数据校验。USE BackupEncryptedGO– insert another recordSET NOCOUNT ON;INSERT INTO dbo.testTable DEFAULT VALUES;GOSELECT * FROM dbo.testTable ORDER BY id;USE master;GO– backup transaction log with encryptionBACKUP LOG [BackupEncrypted]TO DISK = N’C:\Tmp\BackupEncrypted_log.trn’WITH CONTINUE_AFTER_ERROR,ENCRYPTION ( ALGORITHM = AES_256, SERVER CERTIFICATE = MasterCert_BackupEncrypted), STATS = 10;GO日志备份操作前，校验表中的三条数据如下图所示：查看备份历史数据完全备份、差异备份和日志备份结束后，查看备份历史记录。use msdbGO– check backupsSELECT b.database_name, b.key_algorithm, b.encryptor_thumbprint, b.encryptor_type, b.media_set_id, m.is_encrypted, b.type, m.is_compressed, bf.physical_device_nameFROM dbo.backupset bINNER JOIN dbo.backupmediaset m ON b.media_set_id = m.media_set_idINNER JOIN dbo.backupmediafamily bf on bf.media_set_id=b.media_set_idWHERE database_name = ‘BackupEncrypted’ORDER BY b.backup_start_date DESC备份历史信息展示如下：从截图中数据我们可以看出，三种备份都采用了证书做备份加密。查看备份文件信息备份历史检查完毕后，在清理测试环境之前，检查备份文件元数据信息，可以成功查看，没有任何报错。USE masterGO– before clean environment, try to get backup files meta info, will be successRESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’展示结果部分截图如下：清理环境清理环境目的是模拟在一台全新实例上还原数据库备份文件。use masterGO– let’s try to simulate a database crash, here we just drop this database.DROP DATABASE [BackupEncrypted];GO– and clean certificate and master key to simulate restore to a new instance.DROP CERTIFICATE MasterCert_BackupEncrypted;GODROP MASTER KEY;GO再次查看备份文件信息清理掉证书和Master Key后，再次查看备份文件信息，此时会报错。因为数据库备份文件已经加密。这种报错是我们所预期的，即就算我们的数据库备份文件被脱库泄漏，我们的数据也可以保证绝对安全，而不会非预期的还原回来。USE masterGO– try to get backup files meta info again after clean environment, will be not success now.RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’报错信息类似如下：Msg 33111, Level 16, State 3, Line 178Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 178RESTORE FILELIST is terminating abnormally.Msg 33111, Level 16, State 3, Line 179Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 179RESTORE HEADERONLY is terminating abnormally.Msg 33111, Level 16, State 3, Line 181Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 181RESTORE FILELIST is terminating abnormally.Msg 33111, Level 16, State 3, Line 182Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 182RESTORE HEADERONLY is terminating abnormally.Msg 33111, Level 16, State 3, Line 184Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 184RESTORE FILELIST is terminating abnormally.Msg 33111, Level 16, State 3, Line 185Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 185RESTORE HEADERONLY is terminating abnormally.部分错误信息截图如下：还原证书文件数据库备份加密，可以有效防止脱库泄漏的安全风险。当然，合法用户需要在新实例上成功还原加密备份文件。首先，创建Master Key；然后，从证书备份文件中，重新创建证书。USE masterGO– so we have to re-create master key, the certificate and open the IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE name LIKE ‘%MS_DatabaseMasterKey%’) BEGIN CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘MasterKey*’; END GOuse masterGO– re-create certificateCREATE CERTIFICATE MasterCert_BackupEncryptedFROM FILE = ‘C:\Tmp\MasterCert_BackupEncrypted.cer’WITH PRIVATE KEY (FILE = ‘C:\Tmp\MasterCert_BackupEncrypted.key’,DECRYPTION BY PASSWORD = ‘aa11@@AA’);GO检查备份文件信息校验备份文件信息，已经可以正确读取。USE masterGO– after re-create certificate, try to get backup files meta info again, will be success.RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’还原已加密完全备份文件首先，尝试还原数据库完全备份文件，成功。USE [master]– restore encrypted full backupRESTORE DATABASE [BackupEncrypted] FROM DISK = N’C:\Tmp\BackupEncrypted_FULL.bak’ WITH FILE = 1, MOVE ‘BackupEncrypted_data’ TO N’E:\SQLDATA\DATA\BackupEncrypted_data.mdf’,MOVE ‘BackupEncrypted_MemoryOptimized’ TO N’E:\SQLDATA\DATA\BackupEncrypted_MemoryOptimized’,MOVE ‘BackupEncrypted_log’ TO N’E:\SQLDATA\DATA\BackupEncrypted_log.ldf’,NOUNLOAD, STATS = 5, NORECOVERYGO还原已加密差异备份文件其次，尝试还原数据库差异备份文件，成功。– Restore encrypted diff backupRESTORE DATABASE [BackupEncrypted] FROM DISK = N’C:\Tmp\BackupEncrypted_DIFF.bak’ WITH FILE = 1, MOVE ‘BackupEncrypted_data’ TO N’E:\SQLDATA\DATA\BackupEncrypted_data.mdf’,MOVE ‘BackupEncrypted_MemoryOptimized’ TO N’E:\SQLDATA\DATA\BackupEncrypted_MemoryOptimized’,MOVE ‘BackupEncrypted_log’ TO N’E:\SQLDATA\DATA\BackupEncrypted_log.ldf’,NOUNLOAD, STATS = 5, NORECOVERYGO还原已加密日志备份文件再次，尝试还原数据库日志备份文件，成功。– restore encrypted transaction log backupRESTORE LOG [BackupEncrypted] FROM DISK = N’C:\Tmp\BackupEncrypted_log.trn’ WITH FILE = 1, MOVE ‘BackupEncrypted_data’ TO N’E:\SQLDATA\DATA\BackupEncrypted_data.mdf’,MOVE ‘BackupEncrypted_MemoryOptimized’ TO N’E:\SQLDATA\DATA\BackupEncrypted_MemoryOptimized’,MOVE ‘BackupEncrypted_log’ TO N’E:\SQLDATA\DATA\BackupEncrypted_log.ldf’,NOUNLOAD, STATS = 10GO检查测试表数据最后，检查测试表的三条测试数据。USE [BackupEncrypted]GO– double check the three recordsSELECT * FROM dbo.testTable ORDER BY id;三条校验数据一致。清理测试环境清理掉我们的测试环境。use masterGO– clean up the environmentDROP DATABASE BackupEncrypted;GODROP CERTIFICATE MasterCert_BackupEncrypted;GODROP MASTER KEY;GO最后总结本期月报我们分享了SQL Server 2014及以上版本如何使用证书实现数据库备份加密技术，在防范脱库安全风险的同时，既能够比较好的保证用户查询性能，又不会带来额外CPU资源的消耗。参考文章SQL Server Transparent Data Encryption (TDE) Performance ComparisonSQLServer · 最佳实践 · 透明数据加密TDE在SQLServer的应用开启TDE的RDS SQL Server还原到本地环境Understanding Database Backup Encryption in SQL Server本文作者：风移阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

摘要在SQL Server安全系列专题月报分享中，我们已经分享了：如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥加密方式实现SQL Server列加密、使用混合密钥实现SQL Server列加密技术、列加密技术带来的查询性能问题以及相应解决方案和行级别安全解决方案这五篇文章，文章详情可以参见往期月报。本期月报我们分享使用SQL Server 2016 dynamic data masking实现隐私数据列的打码技术最佳实践。问题引入在平日的生活中，我们或多或少都经历过广告推销、电话诈骗，不厌其烦，甚至更为严重到银行卡号泄漏、身份证号泄漏等更为严重的情况。这个时候，于是我们就在想有没有技术手段来尽量或最大限度的保护我们隐私数据安全呢？答案是肯定的，SQL Server 2016版本首次引入了dynamic data masking来实现隐私数据列的打码技术，让我们一起来看看如何实现类似于手机号、身份证号、驾照号等隐私数据打码技术。原理分析数据列打码技术的本身我们并不陌生，就是将一些比较私密的数据信息隐藏起来，仅开放给有较高权限的用户查看完整数据。打码技术本身并不会对数据做任何的加密、解密等操作。严格意义上讲，数据打码不是一个完整的数据安全解决方案，但是它可以作为安全策略中重要的一环来有效避免用户隐私数据列的泄漏。让我们一起来看看在SQL Server 2016 dynamic data masking是如何实现的。实现方法创建测试数据库为了测试方便，我们专门创建了测试数据库TestDb。–Step 1 - Create MSSQL sample databaseUSE masterGOIF DB_ID(‘TestDb’) IS NULL CREATE DATABASE [TestDb];GO创建测试表首先，我们创建一张常规表CustomerInfo，来存放客户信息，其中，CustomerPhone列为用户隐私数据，存放了用户的手机号码。–Step 2 - Create Test Table, init recordsUSE [TestDb]GOIF OBJECT_ID(‘dbo.CustomerInfo’, ‘U’) IS NOT NULL DROP TABLE dbo.CustomerInfoCREATE TABLE dbo.CustomerInfo(CustomerId INT IDENTITY(10000,1) NOT NULL PRIMARY KEY,CustomerName VARCHAR(100) NOT NULL,CustomerPhone CHAR(11) NOT NULL);– Init TableINSERT INTO dbo.CustomerInfo VALUES (‘CustomerA’,‘13402872514’),(‘CustomerB’,‘13880674722’),(‘CustomerC’,‘13487759293’)GO创建测试用户为了方便观察和检查测试效果，我们创建一个测试账号DemoUser。– Step3: Create a DemoUser to testUSE [TestDb]GOCREATE USER DemoUser WITHOUT LOGIN;GRANT SELECT ON dbo.CustomerInfo TO DemoUser;GOEXECUTE AS USER = ‘DemoUser’;– Verify dataSELECT * FROM dbo.CustomerInfoREVERT常规情况下，测试账号，可以清清楚楚，明明白白看到用户所有数据，包含客户手机号这种关键的隐私数据。如果，这个用户有不轨之心是非常容易将这些信息泄漏、导出的，安全风险较大。客户手机号打码于是，我们想，如果能够将客户隐私数据，比如，电话号码（身份证号码、银行卡号等）打码的话，那么测试账号就无法查看到用户完整的数据信息了。打码方法如下：– Step4: Alter phone column add data maskUSE [TestDb]GOALTER TABLE dbo.CustomerInfoALTER COLUMN CustomerPhone ADD MASKED WITH(FUNCTION=‘partial(3, “****”, 4)’);由于CustomerPhone是11位数字，我们使用partial方法打码隐藏中间四位，打码符号使用星号，保留前三位和后四位数数字即可。查询打码列打码完毕，我们使用系统试图查看打码列和打码函数：– Step5. Query system view to check data maskSELECT db_name() as database_name, SCHEMA_NAME(schema_id) AS schema_name, tbl.name as table_name, c.name as column_name, c.is_masked, c.masking_function FROM sys.masked_columns AS c WITH (NOLOCK) INNER JOIN sys.tables AS tbl WITH(NOLOCK) ON c.[object_id] = tbl.[object_id] WHERE c.is_masked = 1 AND tbl.name = ‘CustomerInfo’;从结果可以看到我们已经将表TestDb.dbo.CustomerInfo中字段CustomerPhone打码，打码函数为partial(3, “**”, 4)，结果展示如下所示：测试用户查看数据打码完毕后，再次使用DemoUser测试账号查看打码后的数据：– Step6: Demo user to query and verify dataUSE [TestDb]GOEXECUTE AS USER = ‘DemoUser’;– Verify dataSELECT * FROM dbo.CustomerInfoREVERT从查询结果展示来看，客户手机号码列中间四位已经成功打码了，测试账号已经无法获取到完整的客户电话号码了。修改打码符号有时候，有的人会说，我不喜欢星号，能否换个打码姿势，我更喜欢使用字母X。只要你喜欢，随便切换，方法如下：– Step7: What if I want to change the mask sign from * to XUSE [TestDb]GOALTER TABLE dbo.CustomerInfoALTER COLUMN CustomerPhone CHAR(11) MASKED WITH(FUNCTION=‘partial(3, “XXXX”, 4)’);现在打码符号变成了X，展示如下：新增隐私打码列现在我们需要增加一个新的列，用来存放用户email地址，也请同时打码。非常简单，新增列的时候使用email打码函数即可，如下所示：– Step8: and I want to add a new email mask columnALTER TABLE dbo.CustomerInfoADD Email varchar(100) MASKED WITH (FUNCTION = ’email()’) NOT NULL DEFAULT(‘demo.user@test.com’)查询打码列特定值有的人可能会问，手机号码被打码了，这个列会影响我的WHERE语句查询吗？当然不会，因为data mask技术本身并没有对数据做任何修改，只是在展示的时候，打码隐藏掉部分信息而已。– Step9: Demo user to query the specified phone customer infoUSE [TestDb]GOEXECUTE AS USER = ‘DemoUser’;– Verify dataSELECT * FROM dbo.CustomerInfoWHERE CustomerPhone = ‘13880674722’REVERT查询结果展示，手机号码和email地址始终被打码。拷贝存在打码列的表我们说data mask技术并没有加密、修改数据本身。到目前为止，测试账号DemoUser已经无法获取到客人的关键隐私数据了，那么他能够将用户数据Copy、导出吗？让我们做一个简单的测试，DemoUser将表CustomerInfo复制到一个新表CustomerInfo_copied中：– Step10: Ops, if I copy a new table from the data masked table, I can’t get the unmasked data now.USE [TestDb]GOGRANT CREATE TABLE TO DemoUser;GRANT ALTER ON SCHEMA::dbo TO DemoUser;EXECUTE AS USER = ‘DemoUser’;– Verify dataSELECT * INTO dbo.CustomerInfo_copiedFROM dbo.CustomerInfoREVERTGRANT SELECT ON dbo.CustomerInfo_copied TO DemoUser;EXECUTE AS USER = ‘DemoUser’;SELECT * FROM dbo.CustomerInfo_copiedREVERTDemoUser复制了客户信息数据到新表后，查看新表中的数据，依然是被打码的，测试用户无法导出、复制客人的隐私数据。达到了安全策略保护客户隐私数据的目的，展示结果如下：我想要在无码的世界如果有一天DemoUser成了高权限用户，确实需要查看客户隐私数据列，这个时候，我们可以给予测试账号unmask的权限，他就可以看到完整的客户数据了。方法如下：– Step 11: But, how can demo user to query the unmasked data?USE TestDBGOGRANT UNMASK TO DemoUser; EXECUTE AS USER = ‘DemoUser’; SELECT * FROM dbo.CustomerInfo; REVERT; – Removing the UNMASK permission REVOKE UNMASK TO DemoUser;此时，DemoUser查询到的数据，是非常完整的客人数据。删掉打码删除打码，让所有用户回归无码的世界。– Step 12: all the demos have been done, it’s time to drop the mask.USE TestDBGOALTER TABLE dbo.CustomerInfo ALTER COLUMN CustomerPhone DROP MASKED; 最后总结本期月报我们分享了使用SQL Server 2016引入的新特性dynamic data masking实现客户数据打码技术，防止未授权用户查看、导出用户关键隐私数据，最大限度保证用户数据安全性。本文作者：风移阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

阿里妹导读：近日，阿里安全双子座实验室与马里兰大学等高校合作的论文《Covert Security with Public Verifiability: Faster, Leaner, and Simpler 》【1】被欧洲密码年会(Eurocrypt)2019接收。这是国内公司在安全多方计算领域的第一篇顶会论文（Eurocrypt2018只有3篇大陆作者论文，难度可见一斑）。今天，我们邀请阿里高级安全专家鸿程，深入解读业界首个“公开可验证(PVC)” 的安全两方计算方案。安全多方计算介绍安全多方计算（ Secure Multi-Party Computation，MPC）于1986 年由姚期智院士提出【2】。安全多方计算协议允许多个数据所有者在互不信任的情况下进行协同计算，输出计算结果，并保证任何一方均无法得到除应得的计算结果之外的其他任何信息。换句话说，MPC技术可以获取数据使用价值，却不泄露原始数据内容。互联网已经完成了从IT时代向DT时代的转变，数据已经成为DT时代企业的核心竞争力。数据作为一种新能源，只有流动起来才能产生价值。不过，大多数企业考虑到数据安全和个人隐私等问题，对数据共享都非常谨慎。而MPC对打破数据孤岛，实现数据的可控共享，具有重要的理论和现实意义。MPC方案主要可分为基于混淆电路(Garbled Circuit，GC)和基于秘密共享两种。本文主要关注GC类方案。不经意传输(Oblivious Transfer)我们首先介绍一种基础的安全多方计算协议：不经意传输(Oblivious Transfer, OT)。来看一个例子：假设某旅行社拥有N个景点的旅游资料，小淘想去其中的A景点游玩，希望向旅行社购买相关资料做好出游功课。但是小淘非常在意自己的隐私，不希望向旅行社泄露自己的目的地是哪里。因此双方希望这笔交易能够满足以下隐私条件：小淘不希望向旅行社泄露“我准备去A景点”这一信息；旅行社只希望出售小淘出钱购买的那份资料，而不泄露小淘未购买的N-1份资料；粗看起来这种隐私条件似乎是无法满足的：旅行社只要把景点A的资料给到小淘，就必然了解了“小淘正在关注A景点”这一信息；除非旅行社把所有N份资料都给出，但是这又违背了旅行社的利益；但是神奇的OT可以让交易在这种“不可能的条件”下达成。简而言之，在OT协议中，旅行社把他拥有的N份资料使用某种双方协商同意的加密算法和参数进行加密，然后发送给小淘；小淘可以从密文中解密出A的资料，而无法解密出其他N-1份资料。OT除了可以直接用于构造MPC方案之外，也是GC等许多MPC方案的基石。混淆电路我们知道，任意函数最后在计算机语言内部都是由加法器、乘法器、移位器、选择器等电路表示，而这些电路最后都可以仅由AND和XOR两种逻辑门组成。一个门电路其实就是一个真值表，例如AND门的真值表就是：例如其中右下格表示两根输入线(wire)都取1时，输出wire=1：即 1 AND 1 = 1。假设我们把每个wire都使用不同的密钥加密，把真值表变成这样：例如其中右下格表示如果门的输入是b和d，那么输出加密的f(密钥是b和d)。这个门从控制流的角度来看还是一样的，只不过输入和输出被加密了，且输出必须使用对应的输入才能解密，解密出的f又可以作为后续门的输入。这种加密方式就称为“混淆电路(Garbled Circuit，GC)”。将电路中所有的门都按顺序进行这样的加密，我们就得到了一个GC表示的函数。这个函数接收加密的输入，输出加密的结果。假设有两个参与方A和B各自提供数据a、b，希望安全的计算约定的函数F(a,b)，那么一种基于GC的安全两方计算协议过程可以非正式的描述如下：细心的同学一定会指出：第4步中A怎么可以接触B的输入b呢？这不是违背了安全多方计算的假设吗？这里就需要使用OT，A扮演Sender，B扮演Receiver，让B从A处得到Encrypt( b)，却不向A透露b的内容。如图所示：需要注意的是，上述流程只是最原始的GC方法的不严谨描述，GC后续还有Point & Permute、Free XOR、Half Gates等多种细节优化，随着最近几年的研究进展，GC的性能已经差不多可以实用了。以求两个百万维向量的汉明距离(Hamming Distance)为例（应用场景是两份数据求相似度，却互相不泄露数据内容），这样的安全两方计算已经可以在1.5秒左右完成。安全多方计算的安全模型半诚实行为模型与恶意行为模型更细心的同学还会进一步提出问题：“怎么确保A给B的就是一个正确的GC呢？例如A和B商定要比a和b的大小，商定了F(a,b)=a>b?1:0，但是A可以制作一个别的函数的GC，例如F(a,b)=b的第1个比特，这样显然是会侵害B的隐私的，但是由于函数是以GC形式发给B的，B是没有办法发现这个问题?”这确实是一个安全问题，事实上，GC还存在如selective failure等其他更多的安全问题。在介绍解决方案之前，我们需要先定义安全多方计算的安全模型。安全多方计算的安全模型包含多个角度的内容，在上述上下文中，我们关注的是其中的“行为模型”，即参与方可能进行何种行为以获取其他方的隐私。常见的行为模型包括“半诚实(Semi Honest)”和“恶意(Malicious)”两种。前者假设所有参与方都是忠实的按照协议步骤进行执行，只是想通过协议内容推测其他方的隐私，而后者假设恶意参与方为了获取其他方的隐私可以不遵循协议内容。用扑克牌打个不严谨的比方，半诚实的牌友会试图从自己的手牌和已经打出的牌来推测他人的手牌，但是还是遵循扑克牌规则的；而一个恶意的牌友则换牌、偷牌等手段无所不用。可见，本节开始提出的问题属于恶意行为的范畴，而原始的GC只能说在半诚实行为模型下是安全的，无法抵御恶意行为攻击。有许多对GC方案的改进方案可以达到恶意行为模型下的安全性，但是它们都需要付出很大的性能代价：仍然以求两个百万维向量的汉明距离为例，其中最快的方法也需要10秒+，比同等的半诚实方案慢7倍以上。事实上，经过我们的调研，若想真正的实现支持大规模数据的MPC产品，基本上只能考虑半诚实方案。这严重影响了安全多方计算的实用性。公开可验证(Public Verifiable Covert, PVC)行为模型PVC是在半诚实、恶意之间的一种折中。其主要思想是：每个参与方的所有行为都自动带有类似签名的机制以供其他参与方存证。假设某个参与方实施恶意行为，那么其他参与方可以有的概率发现（称为威慑因子，一般>=50%，不能100%发现，因为100%那就直接满足恶意行为模型了）这一恶意行为，并将该行为及其签名公开，令作恶者承受名誉损失。考虑到名誉对一个数据所有者的重要性（例如此后可能再也找不到合作），50%左右的威慑力已经足以让理性者不考虑作恶。PVC模型最开始是由学者在Asiacrypt2012【3】提出，Asiacrypt2015【4】上也有学者提出相关的改进方案，但是这些方案不仅效率较低，而且只有复杂的理论描述，实现可能性低。我们提出的新型PVC方案不仅协议简洁，性能有大幅提升，而且首次进行了完整的代码实现。仍然以求两个百万维向量的汉明距离为例，使用我们威慑因子为50%的PVC方法大概只需要2.5秒。以下仍假设有两个参与方A和B各自提供数据a、b，希望安全的计算约定的函数F(a,b)，以威慑因子=50%为例，给出我们的PVC方案的非正式描述：A选择两个随机种子s1和s2， B和A运行OT随机选择其中一个（不妨设B获取了s1）；A使用s1和s2分别生成GC1和GC2；B和A运行OT获取GC1中B输入wire的加密值（我们后面可以看到GC1不会真正被使用，因此这里可以不与b对应，比如是任意常数值的密文）；B和A运行OT获取GC2中B输入wire对应的b的加密值；A对GC1进行Hash，并把Hash发给B；A对GC2进行Hash，并把Hash发给B；A对上述所有流程进行签名，并把签名发送给B；B由于有s1，因此可以自行生成GC1，可以自己模拟第3步和第5步；如果结果与A发的不一致，则公布相关签名作为A作恶证据。如果一致，就用GC2进行真实计算。可见，A如果作恶，总有50%的概率被B抽查到（因为A不知道B到底掌握了哪个GC的随机种子）。因此理性的A会选择不作恶，忠实的执行安全多方计算协议。需要再次强调的是，为便于理解，所有的协议都仅仅是非正式描述，有兴趣进一步研究细节的同学欢迎参阅我们的论文【1】。总结我们与马里兰大学等高校合作，首次实现了一种“公开可验证(PVC)” 的安全两方计算方案，这种方案的性能接近半诚实方案，同时其PVC特性能够对作弊行为形成威慑力，令其具有远强于半诚实模型的安全性，具有很高的实用价值。本文作者：鸿程阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

又一年RSA大会归来。每一年参会，总会有一些不同的感悟，或是发现全球安全行业的新趋势，或是找到志同道合的新伙伴，或是看到很多人也相信我们相信的安全技术新方向。今天在回国的航班上提笔写下我的感悟和判断，希望对安全领域里的产品和技术同学们有所启发。回顾每一年RSA的主题都有寓意。2017年的主题“Power of Opportunity”，2018年的主题是“Now Matters”。2017年我印象深刻的是大家都在讨论数据智能及AI对安全的影响，所以主题讲的是机遇（Opportunity）。2018年数据安全及GDPR对产业的影响很深，大会主题便强调安全迫在眉睫，强调此时此刻。今年的主题是“Better“，也寓含全球整个安全市场的爆发和安全产品技术的成熟，大家一起to get better。1.Cloud SIEM成为云服务提供商和安全厂商的必争之地Azure和Google在RSA期间都发布了Cloud SIEM的产品，可以让用户基于云端安全能力从云上覆盖云下的业务。这意味着企业在混合云状态下，可以从一个更全局的视角来进行安全管理运营。此外，Google近日也发布了一款网络安全产品“Backstory”，堪称威胁态势版“Google”，因其“无限扩展”能力，以及使用了构造Google基础设施核心的威胁分析引擎而引人注目。同时我也发现今年各大安全厂商也将SIEM来作为自己的主打产品。基于企业各项数据通过用户行为分析（UEBA），基于设备的威胁检测，基于IP和域名告警来实现全局安全智能分析。不论是云服务提供商还是安全厂商现在都希望通过抢占SIEM(安全信息与事件管理平台)市场。我认为本质还是大家都知道在数据时代谁拥有数据就拥有更多可能。随着Cloud SIEM的成熟，也许未来企业用户会在安全管理平台内集成多家厂商的威胁检测及响应引擎来尽可能提升效果。2.创新沙盒的冠军让我们看到安全基础建设的重要性今年RSA创新沙盒的冠军Axonius。其核心优势在于解决了企业资产管理不全的痛点。Axonius可以帮助企业降低攻击面并能与其他安全产品进行联动。这个概念并不超前。我们看到在过去的一年里，无论是有广泛市场需求的数据安全领域还是机器学习及AI在安全领域的应用，安全技术上没有出现突破性/颠覆性的创新。当谈到云上安全的最佳实践，企业安全体系重要的不仅仅是梳理资产，减少攻击面。我认为更重要的是1. 建立统一的身份认证授权体系、2. 安全基线的运营、3. 全局漏洞管理、4. 默认安全流程策略、5. 敏感数据加密。这个组合拳才是整个企业安全的基石。在这些基础领域之上提升6. 威胁检测、7. 事件调查、8. 自动化响应、9.安全溯源能力才能让整个体系更稳固。3.零信任安全的背后是身份认证将成为企业新的边界今年零信任理念也是热点之一。各厂商纷纷推出各种零信任安全产品。大部分零信任安全产品的背后将身份认证作为核心，因为身份认证将成为企业新的边界。我认为随着企业使用大量的SAAS服务、移动互联网BYOD带来的影响，大量企业应用上云，原来企业安全体系以网络边界为核心的防御理念将随之变化。身份认证将成为企业新的安全边界。基于统一的身份认证，制定不同的安全策略，建立分层授权体系，全面实时的安全智能分析能力将构建未来每个企业安全的基石。4.数据安全领域蓄势待发企业越来越重视数据安全，但因为数据安全领域横跨各个安全技术领域，导致各项数据安全方案成熟度不足。过去的一年里无论是在加密计算领域，还是在SGX可信计算领域，数据安全技术还没有大的创新突破。即便是去年创新沙盒的冠军BigID仍然是以合规驱动为主。过去一年从企业数据泄漏事件来看，数据安全技术和方案还需要提升成熟度。之前数据安全领域主要以DLP（数据防泄漏）技术为主，这两年有越来越多的数据安全厂商开始把用户行为分析、数据防泄漏、数据加密、数据流分析多种技术相结合来提升数据泄漏的检测防御效果。但我认为数据安全涉及各个领域，也不仅仅依赖于检测和响应，身份认证授权也是关键。而未来待加密计算和可信计算技术的成熟，数据安全领域也会有更大的突破创新。5.DevSecOps将得到越来越多企业的重视安全工作不能总是在事中或事后，安全工作越前置企业所付出的成本越低。阿里在2005年安全体系建设初期就开始构建SDL（安全开发流程），这也有效的降低安全漏洞数量及各项安全风险。越来越多的企业已经意识到安全评估、自动化检测必须内嵌在整个产品开发生命周期中才能确保业务及代码的安全。而今年我们看到越来越多安全厂商通过黑白盒自动化检测、RASP（运行态应用防护技术）相结合来构建DevSecOps安全方案。我相信接下来的1-2年DevSecOps安全开发流程会被更多的企业接受，整体安全方案成熟性也会逐步提升。6.安全厂商产品融合趋势明显，自动化响应建立完整安全闭环安全涉及所有技术领域导致安全产品非常碎片化，安全厂商细分领域众多。例如涉及网络安全就有DDoS防御、WAF、防火墙、IPS、RASP等多款安全产品，如果在客户场景部署就像“羊肉串”。这对用户运维管理、网络稳定性、安全运营都提出了很大的挑战。今年安全厂商趋势，试图通过多个产品融合来重新定义安全产品，提供用户更完整的安全产品。这个趋势在今年各家厂商推出的产品形态上非常明显。例如原来做终端EDR的厂商尝试将DLP技术整合至产品中。当前热门的SDP（软件定义边界）领域，厂商就结合SDWAN技术打造云端All in one安全产品来给用户进行集中流量清洗及防护。Palo Alto Networks原来是以网络防火墙为核心产品的厂商。近年来通过投资并购，产品领域已成扇形扩展，已覆盖终端安全、威胁情报、XDR(云端威胁检测及响应）。整个公司战略方向很明确，希望覆盖企业全局安全管理平台，我相信SEIM产品也会不久推出。另一方面自动化响应成今年各安全厂商产品形态又一个明显的变化趋势。我们看到安全厂商的共性：统一数据收集/ 全局威胁检测/ 自动化事件调查 /自动化响应几乎大部分Top安全厂商都在努力实现这样的完整安全闭环。前几年大家都很关注安全的Visibility，因此态势感知成为安全焦点。但是检测、Visibility能力只是原来的痛点，今年各大厂商产品都在往自动化响应闭环发展。当然这也对安全智能、事件关联分析技术和产品API化提出更高的要求。7.云安全成为最热焦点今年42%安全厂商涉及云安全，云安全成为各厂商最热点话题。主要原因是越来越多厂商推出“云安全产品”，基于本地化部署的系统上传安全数据至云端进行分析，共享云端威胁情报的能力，从而提供精准的安全决策。我还发现多家MSSP（安全服务提供商）推出基于多云的安全管理平台，可以集成AWS、Azure云安全中心的威胁检测结果，也可以集成各家安全厂商产品数据结果，最终用户可以在混合云的情况下，实现安全一站式的管理，统一安全视角。随着企业越来越多的上云，如何通过数据及AI的能力解决原来企业安全痛点，是各家厂商努力的方向。另外有一点非常有意思，海外的安全厂商几乎没有私有云的安全解决方案，云安全产品主要面向各家公共云场景。这个是当前云计算发展国内与海外最大的不同。8.构建基于API的安全生态我认为海外安全厂商的产品默认API化做的很好，可以方便给其他安全厂商进行集成，也让企业用户易于整合管理。这是海外和国内安全厂商差异所在。海外安全厂商专注在一个技术点的公司比比皆是，而国内安全公司大部分产品策略是以做多做全为主。我相信这其中也体现了国内市场和厂商的无奈。所以国外安全厂商产品天然需要和其他安全产品进行整合，自身产品就非常重视API化。随着云安全不断发展，云服务提供商和安全厂商也开始进行融合。当前全球多家安全厂商通过云产品API来构建基于云平台的安全产品。云服务提供商也集成安全厂商的API来提供云安全产品服务更多的用户。云服务提供商的安全产品API也被安全厂商集成到线下产品来提升能力。我相信用户最终需要的是能够集成各家核心安全能力，打造最佳的防御体系来应对网络安全对业务所带来的风险。9.安全厂商的品牌价值凸显如果说技术代表的是厂商的核心竞争力，那品牌展示则更清晰表达出其定位和差异化。我收集了一些安全厂商的标语，这些标语里面也体现了各家安全厂商的核心优势、品牌理念及市场定位。例如Chronicle强调安全智能、McAfee强调协同、VMware强调云原生安全和智能、AWS强调云上能够提升企业安全性。我个人更喜欢IBM Security的标语：“我们并不需要更多的安全工具，我们需要新的安全规则”。我相信互联网安全环境越来越好也一定离不开政策、法律、合作、技术创新。Chronicle : Global Secruity Intelligence （全球化的安全智能）；IBM Security： We don’t need more tools. We need new rules （不安全的世界，需要的并不是更多的安全工具，而是新的安全规则）；McAfee : Together is Power（产品协同，所有人齐心协力才是最大的力量）；VMware： Intrinsic Security，Intelligent Protection（原生安全，智能保护）；AWS ： Elevate the security（云上提升安全性）。10.展望其他安全技术领域1、在今年RSA大会上业务风控的公司不多，主要以防Bot厂商为主。但我相信随着黑灰产的发展，黑产变现方式不止局限于DDoS攻击、挖矿这类事件。未来黄牛党、广告点击欺诈、防撞库等业务安全问题会对企业业务有更多影响，而业务安全领域也将逐渐成为安全市场主流需求。2、随着Cloud SEIM的兴起以及这两年部分厂商推出MDR（可管理的检测及响应服务），我相信MSSP（安全托管服务）会被越来越多的用户所接受。而这个前提条件就是安全SAAS服务的兴起，国内目标在SAAS服务上用户接受度还不足，我预期随着云计算的发展接下来几年一定会有更大的爆发。3、今年IoT和移动安全厂商非常少，尤其是过去几年大家都很看好的IoT安全领域。这也说明整个IoT市场还在混沌阶段，我也相信IoT安全市场发展要取决于IoT OS之战。从移动互联网走到云时代再到IoT万物互联的时代，不同时代操作系统的安全水位决定了安全市场的大小和走向。我也期待着在云计算和万物互联时代真正到来时，我们能让用户及企业在互联网上更安全无忧的发展业务，帮助他们服务全球用户。本文作者：云安全专家阅读原文本文为云栖社区原创内容，未经允许不得转载。

AES的相关基础知识直接看WikiPedia：高级加密标准附上 C/C++ 可用代码：AES_Cipher

一.对称加密1.原理通信双方使用同一个密钥，使用加密算法配合上密钥来加密，解密时使用加密过程的完全逆过程配合密钥来进行解密。2.例子原始字符：ABCDEFGHIJKLMNOPQRSTUVWXYZ 密码字符：BCDEFGHIJKLMNOPQRSTUVWXYZA 原始书信：I love you 加密书信：J mpwf zpv 解读后：I love you这里的算法就是每个字符采用后一位的字符替换，密钥就是原始的英文字母表。3.算法DES（56 位密钥，密钥太短被逐渐被弃用）AES（128 位、192 位、256 位密钥，现在最流行） 密钥长增加破解的难度和成本4.缺点因为加密和解密都用的相同的密钥，如果密钥再传输过程中被截获，那么信息很容易就会被破解甚至伪造身份（如网络通信过程中，A和B是两个不认识的用户要通信，那么A要把密钥先传给B再开始通信，这样B在接收密钥的过程中可能被第三方劫持从而造成密钥的泄露，第三方取到密钥后便可以破解加密信息）。5.破解思路拿到一组或多组原文-密文对 设法找到一个密钥，这个密钥可以将这些原文-密文对中的原文加密为密文，以及将密文解密为原文的组合，即为成功破解。反破解 让破解者找不到穷举法（暴力破解法，可以理解为一个一个尝试）更有效的破解手段，并 且穷举法的破解时间足够长（例如数千年，那么认为不可破解）。二.非对称加密1.原理使用公钥对数据进行加密得到密文；使用私钥对数据进行解密得到原数据，加密解密用的算法相同，公钥私钥互相是可解的（所以可以用于数字签名技术,但双方不能替换，因为公钥是要暴露出去的，是可以被劫获的）。2.例子原数据：110 —->加密算法都是普通的加法 公钥是加4，私钥是加6加密数据:554 解密数据:111110 —->去掉每个的第一位，得出原数据110（注意：溢出是满足非对称加密一个很重要的条件）。3.签名验证由于私钥和公钥互相可解，因此非对称加密还可以应用于数字签名技术（主要是为了验证数据的来源，也就是要确定是我给你发的数据而不是别人给你发的数据,防止数据被篡改被伪造）。发送方用自身私钥加密，接收方获取签名数据后用发送方的公钥解密（验证）获取原数据，然后用获取的原数据和发送来的原数据比对是否一致，一致则证明数据是从目标发送过来的。通常会将原数据做hash处理后再加密，降低原数据签名后的数据大小（例如你要传10G大小的文件，那么原数据10G，作为比对的签名数据难道也要放10G吗？不能这么做，非常消耗流量和速度。所以直接对文件的hash值进行签名，最后比对hash值即可）。为什么签名验证可以证明数据的来源是安全的(也就是是我发的而不是别人伪发或伪造的)模拟场景：伪造方换原数据–>签名数据验证以后的Hash和伪造数据的Hash不相同，验证失败。伪造方换原数据和签名数据–>公钥验证后的数据和被换数据的Hash不符，验证失败。（因为签名数据是用的换数据方自身私钥签名的，只有与其对应的公钥可以还原回原Hash值，但此时用的还是原数据方的公钥去做的验证，所以公钥解密后得到的并不是伪造数据的Hash值）。综上：信息是没有被伪造可能的。4.加密解密、签名验证的配合使用（开发中常见的使用方式）4.1 例子使用非对称加密通信，可以在不可信网络上将双方的公钥传给对方，然后在发消息前分别对消息使用 对方的公钥来加密和使用自身的私钥来签名，做到不可信网络上的可靠密钥传播及加密通信。A和B通信,首先B要把自己的公钥发给A，A用B自己的公钥加密数据传给B，B再用自己的私钥解密。但是公钥因为是暴露的，可能被C获得，那么C获取B的公钥后完全可以自己发伪造消息给B，所以A和B通信的时候B需要知道信息是A发送的，所以通信中A会把自身的公钥发给B，再发送数据的时候对数据用自身的私钥加密，因为公钥私钥互相可解，发送到B后B用A的公钥去解密，比对用B公钥加密B私钥解密和A私钥加密（签名）A公钥解密（验证）的数据结果是否一致，如果一致则证明是A发送的数据而不是别人篡改过的数据。5.优点可以在不安全网络上传输密钥，公钥别人拿到也没用，因为他没有私钥无法解数据，而私钥又不会传给别人只是自身持有，没有泄露的风险 。6.缺点计算复杂，因此性能相比对称加密差很多。7.算法RSA（可用于加密和签名）、DSA（仅用于签名，但速度更快）8.破解思路和对称加密不同之处在于，非对称加密的公钥很容易获得，因此制造原文-密文对是没有困难的事 所以，非对称加密破解的关键只在于，如何找到找到正确的私钥，可以解密所有经过公钥加密过的密文。找到这样的私钥即为成功破解 由于非对称加密的自身特性，怎样通过公钥来推断出私钥通常是一种思路（例如 RSA），但往往 最佳手段依然是穷举法，只是和对称加密破解的区别在于，对称加密破解是不断尝试自己的新密钥是否可以将拿到的原文-密文对进行加密和解密，而非对称加密是不断尝试自己 的新私钥 是否和公钥互相可解。三.延伸知识： Hash1.是什么?把任意数据转换成指定大小范围（通常很小，例如 256 字节以内）的数据。2.算法MD5SHA2563.作用从数据中提出摘要信息，因此最主要用途是数字指纹。 （也就是根据数据的所有特征算出一个值）。4.例子public class A{private String name;private int age;private void hashCode(){ //只是举一个例子，实际中的hashCode计算要比这个复杂很多，因为要尽量减少Hash碰撞的概率. return name.length()+age;}}5.用途唯一性验证例如 Java 中的 hashCode() 方法。怎么重写 hashCode 方法？把 equals() 方法中的每个用于判断相等的变量都放进 hashCode() 中，一起生成一个尽量不会碰撞的整数即可 。为什么每次重写 equals() 方法都需要？因为你要把新的判断条件放进 hashCode() 。特别注意:hashCode相同不代表对象相同,因为它只是数据的特征值,equals方法相同对象才是一样的,但hashCode可以用于快速检查对象是否相同，毕竟hashCode只是一个值的比较，而equals是多个值的比较。6.实际用途6.1 数据完整性验证从网络上下载文件后，通过比对文件的 Hash 值（例如 MD5、SHA1），可以确认下载的文件是否有损坏。如果下载的文件 Hash 值和文件提供方给出的 Hash 值一致，则证明下载的文件是完好无损的。6.2 快速查找HashMap（通过hashCode/Map的长度-1算出一个余数，根据余数确认在数组中的index位置，参考HashMap源码）。6.3 隐私保护当重要数据必须暴露的时候，有时可以选择暴露它的 Hash 值（例如 MD5），以保障原数据的安全。 例如网站登录时，可以只保存用户密码的 Hash 值，在每次登录验证时只需要将输入的密码的 Hash 值和数据库中保存的 Hash 值作比对就好，网站无需知道用户的密码。这样，当网站数据失窃时，用户不会因为自身的密码被盗导致其他网站的安全也受到威胁（有可能设置的密码都是相同的）。7.Hash 是加密吗？不是（划重点！！！）。Hash 是单向过程，无法进行逆向恢复操作（10G的文件进行hash后可能hashcode只有几KB大小，那么这几KB怎么可能恢复成10G的原文件呢），因此 Hash 不属于加密。（MD5不是加密！！） ...

本文由云+社区发表作者：mariolu一、什么是PSS模式？1.1、两种签名方式之一RSA-PSSPSS (Probabilistic Signature Scheme)私钥签名流程的一种填充模式。目前主流的RSA签名包括RSA-PSS和RSA-PKCS#1 v1.5。相对应PKCS（Public Key Cryptography Standards）是一种能够自我从签名，而PSS无法从签名中恢恢复原来的签名。openssl-1.1.x以后默认使用更安全的PSS的RSA签名模式。1.2、填充的必要性RSA算法比较慢，一般用于非对称加密的private key签名和public key验证。因RSA算法沒有加入乱数，当出现重复性的原始资料，攻击者会通过相同加密密文而猜测出原文，因此导入padding的机制來加強安全性。TLS流程中的密钥材料若不进行填充而直接加密，那么显然相同的key，会得到相同的密文。这种在语义上来说，是不安全的。以下例子说明了无填充模式的安全漏洞。m：明文e，n：RSA参数（公钥）d：RSA参数（私钥）c：网络传输密文加密方加密m：c = m^e mod n，传输c解密方解密c：m = c^d mod n，还原mc’：篡改密文k：篡改码由于c在网络上传输，如果网络上有人对其进行c’ = ck^e mod n，这样的替换那么解密方将得到的结果是(ck^e)^d mod n= （c^d mod n）* （k^ed mod n）= m*k即中间人有办法控制m。1.3、PSS的基本要素使用PSS模式的RSA签名流程如下：图1、RSA-PSS的填充模式相比较PKCS#1 v1.5的padding简单许多：图2、RSA-PKCS#v1.5的填充模式PSS的一些概念：hash算法，一般使用SHA-1MGF函数（mask generation function)。默认是MGF1。salt length，一般由hLen决定。当为0时，签名值变成了唯一确定的。截断符号，一般是0xbc二、RSA签名实际操作这节例子中所涉及到的文件说明：/tmp/wildcard_domain.sports.qq.com.v2.key：私钥/tmp/pub: 公钥/tmp/data: 明文/tmp/endata: 密文/tmp/sign: 签名/tmp/de_sign: 解签名2.1、前期准备：公钥和私钥通过key文件提取出public keyopenssl rsa -in /usr/local/services/ssl_agent/ca/wildcard_domain.sports.qq.com.v2.key -pubout -out /tmp/pub原始数据：echo -n “1234567890” > /tmp/data这样就有一对公钥和私钥，用来测试RSA加密解密（encrypt、decrypt）和签名验证（sign，verify）RSA加密的两种算法分别是RSAES-PKCS-v1_5 and RSAES-OAEP。2.2、加密和解密（encrypt，decrypt）加密：openssl rsautl -pubin -inkey /tmp/data -in /tmp/data -encrypt -out /tmp/endata解密，用private key解密，得到原本的值：openssl rsautl -inkey /tmp/wildcard_domain.sports.qq.com.v2.key -in /tmp/en_data -decrypt2.3、签名和验证（sign, verify）签名过程包括hash和加密。hash函数一般使用sha1。这样输入明文，直接生成sign签名。如果是私钥签名所做的事就是先hash再加密，选择一种hash算法把原始消息计算后成ASN1格式，再把这个资料用private key加密后送出，资料本身不加密，这种方式主要是用來验证资料来源是否可信任的，送出時把原始资料和签名一起送出。签名：openssl sha1 -sign /tmp/wildcard_domain.sports.qq.com.v2.key /tmp/data > /tmp/data/sign/tmp/data/sign解开签名：openssl rsautl -pubin -inkey /tmp/pub -in sign -verify -out /tmp/de_sign 用public key解开签名，并且保留padding openssl rsautl -pubin -inkey /tmp/pub -in /tmp/sign -encrypt -raw -hexdump使用解开ASN1解开签名，或者签名后用ASN1工具解析openssl rsautl -pubin -inkey /tmp/pub -in /tmp/sign -verify -asn1parse或者：openssl asn1parse -inform der -in /tmp/de_sign和本地sha1对比openssl sha1 /tmp/data如果两者hash结果是一样，那么确定签名送过来是正确的。2.4、openssl rsautl工具支持的填充模式openssl rsautl –help，可以看到支持的padding模式有，在rsautl加上以下选项可以重复做2.2~2.3的实验。 -ssl Use SSL v2 padding -raw Use no padding -pkcs Use PKCS#1 v1.5 padding (default) -oaep Use PKCS#1 OAEP三、PSS填充模式的特点PSS是RSA的填充模式中的一种。完整的RSA的填充模式包括：RSA_SSLV23_PADDING（SSLv23填充）RSA_NO_PADDING（不填充）RSA_PKCS1_OAEP_PADDING （RSAES-OAEP填充，强制使用SHA1，加密使用）RSA_X931_PADDING（X9.31填充，签名使用）RSA_PKCS1_PSS_PADDING（RSASSA-PSS填充，签名使用）RSA_PKCS1_PADDING（RSAES-PKCS1-v1_5/RSASSA-PKCS1-v1_5填充，签名可使用）其中主流的填充模式是PKCS1和PSS模式。PSS的优缺点如下：PKCS#1 v1.5比较简易实现，但是缺少security proof。PSS更安全，所以新版的openssl-1.1.x优先使用PSS进行私钥签名（具体在ssl握手的server key exchange阶段）此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号 ...

Weblogic SSL证书部署 、 SSL证书申请注：请认真细读里面的每个步骤。针对不同系统安装的weblogic 需要调整不同的启动文件，此目的是为了提示低版本的weblogic可以支持TLS1.0以上安全协议和提升安全加密套件而制作。注意：首先要额外（Windows：安装jdk新的版本）或是（Linux或centos：编译安装jdk新版本）。然后记住安装编译的路径。Windows 版本weblogic1：根据您安装weblogic目录和您创建用户的账户路径而定：我的测试环境如下例如：1.1：（C:OracleMiddlewareuser_projectsdomainszzidc.com）我的账户目录。1.2：来到账户中的（bin）目录中。1.3：修改前备份好原始文件（必需做的一步，以防万一。可以恢复原始）。找到此文件 “setDomainEnv.cmd”（linux环境修改setDomainEnv.sh）用记事本打开，接着找到里面set WL_HOME 的参数段，如下: 保存重启即可。1.4：最后通过openssl 来测试是否已经启用了TLS1.0以上的安全协议，可以运用此命令：首先你得有Openssl的插件目录（我的环境：D:OpenSSL-Win64bin>。Linux下也可以检测）通过命令定位到openssl的bin路径下。1.5：输入命令：openssl s_client -connect test.yibaomd.com:443 –status红色部分可以换成你的IP或是域名。执行结果：如图提示：Protocol： TLSv1.2 就说明指定替换成功。1.6：以上为安全协议已经是调整为最佳状态。接下来就是要调整加密套件。可以参考此路径中的tomcat7方案进行调整：https://bbs.wosign.com/forum….1.7：同样：首先到您的账户目录中的config的目录中找到：config.xml的配置文件用记事本打开：找到到“<SSL></SSL>”的节点。加入红色的套件（以下为测试环境加密套件仅作参考）如需额外根据环境调整请参考上诉提供的BBS论坛中的自行调整。<ssl><enabled>true</enabled><ciphersuite>TLS_RSA_WITH_AES_128_CBC_SHA</ciphersuite><ciphersuite>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</ciphersuite><ciphersuite>TLS_RSA_WITH_AES_128_CBC_SHA256</ciphersuite><ciphersuite>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</ciphersuite><hostname-verification-ignored>true</hostname-verification-ignored>。。</ssl>最好保存1.8：调整加密套件后就需要测试是否真正达到和提升服务器安全需要通过扫描工具进行扫描：https://wosign.ssllabs.com/ 扫描的域名必须默认443端口：如下图：未调整前结果：调整后结果：大功告成。。。。。。。。。。。。。沃通技术支持原创文章，转载请注明来源

以下是显示如何使用org.bouncycastle.openssl.PEMWriter的最佳投票示例。 这些示例是从开源项目中提取的。 您可以对您喜欢的示例进行投票，您的投票将在我们的系统中使用，以生成更多好的示例。示例一 保存密钥和证书到文件中/** * 保存私钥和证书至文件 * @throws Exception / protected void saveKeyPairAndCertificateToFile() throws Exception { if(localPrivateKeyFile==null){ LOGGER.info(“not saving private key nor certificate”); return; } //Encode in PEM format, the format prefered by openssl// if(false){// PEMWriter pemWriter=new PEMWriter(new FileWriter(localPrivateKeyFile));// pemWriter.writeObject(localPrivateECKey);// pemWriter.close();// }// else{ String keyText = “—–BEGIN EC PRIVATE KEY—–\n” + Base64.encode(Unpooled.wrappedBuffer(localPrivateECKey.getEncoded()), true).toString(CharsetUtil.US_ASCII) + “\n—–END EC PRIVATE KEY—–\n”; Files.write(keyText, localPrivateKeyFile, CharsetUtil.US_ASCII); Files.write(localId.toString(), new File(localPrivateKeyFile.getParentFile(), “localPublic.hash”), CharsetUtil.US_ASCII);// } PEMWriter certificateWriter=new PEMWriter(new FileWriter(localCertificateFile)); certificateWriter.writeObject(cert); certificateWriter.close(); LOGGER.info(“Saved to “+localCertificateFile.getAbsolutePath()); }示例二 ：对私钥进行加密/* * 加密私钥 * * @param key 私钥对象 * @param algorithm 密钥算法 * @throws NoSuchProviderException * @throws NoSuchAlgorithmException * @throws IOException / private void encryptedTest(PrivateKey key, ASN1ObjectIdentifier algorithm) throws NoSuchProviderException, NoSuchAlgorithmException, IOException { ByteArrayOutputStream bOut = new ByteArrayOutputStream(); PEMWriter pWrt = new PEMWriter(new OutputStreamWriter(bOut), “BC”); PKCS8Generator pkcs8 = new PKCS8Generator(key, algorithm, “BC”); pkcs8.setPassword(“hello”.toCharArray()); pWrt.writeObject(pkcs8); pWrt.close(); PEMReader pRd = new PEMReader(new InputStreamReader(new ByteArrayInputStream(bOut.toByteArray())), new PasswordFinder() { public char[] getPassword() { return “hello”.toCharArray(); } }); PrivateKey rdKey = (PrivateKey) pRd.readObject(); assertEquals(key, rdKey); }示例三 转换 rsa的私钥为 pem 字符串/* * 转换 rsa的私钥为 pem 字符串 * * @param rsaKeyPair RSA 类型keypair * @return PEM string / public static String getPEMStringFromRSAKeyPair(RSAKeyPair rsaKeyPair) { StringWriter pemStrWriter = new StringWriter(); PEMWriter pemWriter = new PEMWriter(pemStrWriter); try { KeyPair keyPair = new KeyPair(rsaKeyPair.getPublic(), rsaKeyPair.getPrivate()); //pemWriter.writeObject(keyPair); pemWriter.writeObject(keyPair.getPrivate()); //pemWriter.flush(); pemWriter.close(); } catch (IOException e) { log.warning(“Caught exception:” + e.getMessage()); return “”; } return pemStrWriter.toString(); }示例四 将pem 数据对象转换成 pem格式文件数据/* * 将pem 数据对象转换成 pem格式文件数据 * @param object * @return * @throws IOException */ public static byte[] toPem(Object object) throws IOException { ByteArrayOutputStream outputStream = new ByteArrayOutputStream(); try (PEMWriter writer = new PEMWriter(new OutputStreamWriter(outputStream))) { writer.writeObject(object); writer.flush(); return outputStream.toByteArray(); } }示例五 将多份 certificate 对象写入文件private void writeCertificate(Certificate… certificates) throws IOException { final PEMWriter writer = new PEMWriter(new FileWriter(destfile)); for (final Certificate c : certificates) { writer.writeObject(c); } writer.close();}示例六 将 X509Certificate 转换成 pem格式数据public String x509CertificateToPem(final X509Certificate cert) throws IOException { final StringWriter sw = new StringWriter(); try (final PEMWriter pw = new PEMWriter(sw)) { pw.writeObject(cert); } return sw.toString();}示例七 将 rsa私钥对象转换为 PEM 格式数据public String rsaPrivateKeyToPem(final PrivateKey key) throws IOException { final PemObject pemObject = new PemObject(CCS_RSA_PRIVATE_KEY, key.getEncoded()); final StringWriter sw = new StringWriter(); try (final PEMWriter pw = new PEMWriter(sw)) { pw.writeObject(pemObject); } return sw.toString();}示例八 将私钥、证书文件等转换为 PEM数据private static byte[] getPemBytes(Object… objects) throws Exception { ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); try (PEMWriter pemWriter = new PEMWriter(new OutputStreamWriter(byteArrayOutputStream, UTF_8))) { for (Object object : objects) { pemWriter.writeObject(object); } } return byteArrayOutputStream.toByteArray();}示例九 将 X509Certificate 转换为PEM 数据private static String toPem(X509Certificate certificate) throws IOException { StringWriter stringWriter = new StringWriter(); PEMWriter pemWriter = new PEMWriter(stringWriter, BouncyCastleProvider.PROVIDER_NAME); pemWriter.writeObject(certificate); pemWriter.close(); return stringWriter.toString();}示例十 将多个 证书数据 写入文件private void writeCertificate(Certificate… certificates) throws IOException { final PEMWriter writer = new PEMWriter(new FileWriter(destfile)); for (final Certificate c : certificates) { writer.writeObject(c); } writer.close();}示例十一 将keyPair 转换成Pem格式private String keyPairToString(KeyPair keyPair) { StringWriter stringWriter = new StringWriter(); PEMWriter pemWriter = new PEMWriter(stringWriter); try { pemWriter.writeObject(keyPair); pemWriter.flush(); pemWriter.close(); } catch (IOException e) { throw new RuntimeException(“Unexpected IOException: " + e.getMessage(), e); } return stringWriter.getBuffer().toString();} ...

媒体对比特币的关注让我开始了解比特币的真正运作方式，直至流经网络的字节数。普通人使用隐藏真实情况的软件，但我想亲自了解比特币协议。我的目标是直接使用比特币系统：手动创建比特币交易，将其作为十六进制数据提供给系统，并查看它是如何处理的。事实证明这比我预期的要困难得多，但我在这个过程中学到了很多东西，希望你会发现它很有趣。本篇博文首先简要介绍比特币，然后跳转到低级细节：创建比特币地址，进行交易，签署交易，将交易提供给对等网络，并观察结果。比特币的快速概述在深入研究细节之前，我将首先快速概述比特币的工作原理。比特币是一种相对较新的数字货币，可以通过互联网传输。你可以用Coinbase或MtGox等网站上的美元或其他传统资金购买比特币，将比特币发送给其他人，在某些地方用它们买东西，然后将比特币兑换成美元。为了略微简化，比特币由分布式数据库中的条目组成，该数据库跟踪比特币的所有权。与银行不同，比特币与用户或账户无关。相反，比特币由比特币地址拥有，例如1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa。比特币交易交易是消费比特币的机制。在交易中，某些比特币的所有者将所有权转移到新地址。比特币的一个关键创新是如何通过挖掘在分布式数据库中记录交易。交易被分组为块，大约每10分钟发送一个新的交易块，成为交易日志的一部分，称为区块链，表示交易已经（或多或少）正式进行。比特币挖掘是将交易放入块中的过程，以确保每个人都具有一致的交易日志视图。为了挖掘区块，矿工们必须找到一种极其罕见的解决方案来解决（否则无意义的）加密问题。找到此解决方案会生成一个已开采的块，该块将成为官方区块链的一部分。挖掘也是比特币进入系统的新机制。当块成功挖掘时，块中会生成新的比特币并支付给矿工。这个采矿奖金很大——目前每块25比特币（约19,000美元）。此外，矿工获得与区块中的交易相关的任何费用。因此，采矿与许多试图开采矿块的人竞争非常激烈。采矿的难度和竞争力是比特币安全的关键部分，因为它确保没有人可以用坏块淹没系统。点对点网络没有集中的比特币服务器。相反，比特币在点对点网络上运行。如果你运行比特币客户端，你将成为该网络的一部分。网络上的节点彼此交换其他对等体的交易，块和地址。首次连接到网络时，客户端会从某个随机节点或节点下载区块链。反过来，你的客户端可能会向其他节点提供数据。当你创建比特币交易时，你将其发送给某个对等方，该对等方将其发送给其他对等方，依此类推，直到它到达整个网络。矿工获取你的交易，生成包含你的交易的挖掘区块，并将此挖掘的区块发送给对等方。最终，你的客户端将收到该块，你的客户端将显示该交易已处理完毕。加密比特币使用数字签名来确保只有比特币的所有者可以使用它们。 比特币地址的所有者具有与该地址相关联的私钥。 为了花费比特币，他们用这个私钥签署交易，证明他们是所有者。 （这有点像签署物理检查以使其有效。）公钥与每个比特币地址相关联，任何人都可以使用它来验证数字签名。块和交易由其内容的256位加密哈希标识。 此哈希值用于比特币协议中的多个位置。 此外，查找特殊哈希是挖掘块的难题。深入原始比特币协议本文的其余部分将逐步讨论我如何使用原始比特币协议。首先，我生成了比特币地址和密钥接下来，我做了一笔交易，将少量的比特币转移到这个地址。签署此交易给我带来了很多时间和困难。最后，我将这笔交易送入比特币点对点网络并等待它开采。本文的其余部分将详细介绍这些步骤。事实证明，实际使用比特币协议比我预期的更难。正如你将看到的，该协议有点混乱：它使用大尾数字，小尾数数字，固定长度数字，可变长度数字，自定义编码，DER编码和各种加密算法，看似随意。因此，将数据转换为正确的格式会有很多烦人的操作。直接使用协议的第二个复杂因素是加密，这是非常不可原谅的。如果你得到一个字节错误，则会拒绝该交易，而不知道问题出在何处。我遇到的最后一个困难是签署交易的过程比必要的困难得多，需要纠正很多细节。特别是，签名的交易版本与实际使用的版本非常不同。比特币地址和密钥我的第一步是创建一个比特币地址。通常，你使用比特币客户端软件来创建地址和相关密钥。但是，我写了一些Python代码来创建地址，准确显示幕后发生的事情。比特币使用各种键和地址，因此下图可能有助于解释它们。首先创建一个随机的256位私钥。需要私钥来签署交易，从而转移（支出）比特币。因此，私钥必须保密，否则你的比特币可能被盗。Elliptic Curve DSA算法从私钥生成512位公钥。（椭圆曲线加密将在后面讨论。）此公钥用于验证交易上的签名。不方便的是，比特币协议为公钥添加了前缀04。在签署交易之前不会公开公钥，这与大多数公钥公开的系统不同。下一步是生成与其他人共享的比特币地址。由于512位公钥不方便大，因此使用SHA-256和RIPEMD哈希算法将其分解为160位。然后使用比特币的自定义Base58Check编码以ASCII编码密钥。结果地址，例如1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa，是人们为了接收比特币而发布的地址。请注意，你无法从该地址确定公钥或私钥。如果你丢失了私钥（例如丢弃了硬盘），你的比特币将永远丢失。最后，电子钱包交换格式密钥（WIF）用于向客户端钱包软件添加私钥。这只是将私钥的Base58Check编码转换为ASCII，这很容易被反转以获得256位私钥。（我很好奇是否有人会使用上面的私钥来窃取我的80美分的比特币，当然有人这样做了。）总而言之，有三种类型的密钥：私钥，公钥和公钥的hash，它们使用Base58Check编码在ASCII外部表示。私钥是重要的密钥，因为它需要访问比特币，而其他密钥可以从中生成。公钥哈希是你看到的比特币地址。我使用以下代码片段生成WIF格式的私钥和地址。私钥只是一个随机的256位数字。ECDSA加密库从私钥生成公钥。比特币地址由SHA-256哈希，RIPEMD-160哈希，然后是带校验和的Base58编码生成。最后，私钥在Base58Check中编码，以生成用于将私钥输入比特币客户端软件的WIF编码。注意：这个Python随机函数不是强加密；如果你真的这样做，请使用更好的功能。def privateKeyToWif(key_hex): return utils.base58CheckEncode(0x80, key_hex.decode(‘hex’)) def privateKeyToPublicKey(s): sk = ecdsa.SigningKey.from_string(s.decode(‘hex’), curve=ecdsa.SECP256k1) vk = sk.verifying_key return (’\04’ + sk.verifying_key.to_string()).encode(‘hex’) def pubKeyToAddr(s): ripemd160 = hashlib.new(‘ripemd160’) ripemd160.update(hashlib.sha256(s.decode(‘hex’)).digest()) return utils.base58CheckEncode(0, ripemd160.digest())def keyToAddr(s): return pubKeyToAddr(privateKeyToPublicKey(s))# Warning: this random function is not cryptographically strong and is just for exampleprivate_key = ‘’.join([’%x’ % random.randrange(16) for x in range(0, 64)])print keyUtils.privateKeyToWif(private_key)print keyUtils.keyToAddr(private_key)在交易中交易是比特币系统的基本操作。你可能希望交易只是将一些比特币从一个地址移动到另一个地址，但它比这更复杂。比特币交易在一个或多个输入和输出之间移动比特币。 每个输入都是提供比特币的交易和地址。每个输出都是接收比特币的地址，以及到达该地址的比特币数量。上图显示了一个示例交易“C”。在此交易中，0.005BTC取自交易A中的地址，而0.003BTC取自交易B中的地址。请注意，箭头是对先前输出的引用，因此向后转到比特币流。）对于输出，0.003BTC指向第一个地址，0.004BTC指向第二个地址。剩余的0.001BTC作为费用给到该区块的矿工。请注意，交易A的其他输出中的0.015 BTC不会用于此交易。使用的每个输入必须完全花在交易中。如果一个地址在一个交易中收到了100个比特币而你只想花1个比特币，那么交易必须花费所有100个。解决方案是使用第二个输出进行更改，这会将99个剩余比特币返回给你。交易还可以包括费用。如果在将输入相加并减去输出后仍有任何比特币剩余，则余额是支付给矿工的费用。该费用并非严格要求，但免费交易对矿工来说不是优先考虑的事项，可能几天不会处理，也可能完全丢弃。交易的典型费用是0.0002比特币（约20美分），因此费用很低但不是微不足道的。手动创建交易对于我的实验，我使用了一个带有一个输入和一个输出的简单交易，如下所示。我开始使用Coinbase的比特币并将0.00101234比特币放入地址1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5，这是交易81b4c832…我的目标是创建一个交易，将这些比特币转移到我上面创建的地址，1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa，减去0.0001比特币的费用。因此，目标地址将接收0.00091234比特币。遵循规范，可以非常容易地组装无符号交易，如下所示。有一个输入，它使用来自交易81b4c832…输出0（第一个输出）81b4c832…请注意，此交易哈希在交易中不方便地反转。输出量为0.00091234比特币（91234为十六进制的0x016462），以小尾数格式存储在值字段中。加密部分———criptSig和scriptPubKey更复杂，稍后将对其进行讨论。这是我用来生成这个无符号交易的代码。这只是将数据打包成二进制的问题。签署交易是困难的部分，你将在下面看到。# Makes a transaction from the inputs# outputs is a list of [redemptionSatoshis, outputScript]def makeRawTransaction(outputTransactionHash, sourceIndex, scriptSig, outputs): def makeOutput(data): redemptionSatoshis, outputScript = data return (struct.pack("<Q", redemptionSatoshis).encode(‘hex’) + ‘%02x’ % len(outputScript.decode(‘hex’)) + outputScript) formattedOutputs = ‘’.join(map(makeOutput, outputs)) return ( “01000000” + # 4 bytes version “01” + # varint for number of inputs outputTransactionHash.decode(‘hex’)[::-1].encode(‘hex’) + # reverse outputTransactionHash struct.pack(’<L’, sourceIndex).encode(‘hex’) + ‘%02x’ % len(scriptSig.decode(‘hex’)) + scriptSig + “ffffffff” + # sequence “%02x” % len(outputs) + # number of outputs formattedOutputs + “00000000” # lockTime )比特币交易如何签署下图给出了如何签署和链接交易的简化视图。考虑中间交易，将比特币从地址B转移到地址C.交易的内容（包括先前交易的哈希）被哈希并用B的私钥签名。此外，B的公钥包含在交易中。通过执行几个步骤，任何人都可以验证交易是否被B授权。首先，B的公钥必须与前一个交易中的B地址相对应，证明公钥是有效的。（如前所述，地址可以很容易地从公钥中导出。）接下来，可以使用交易中B的公钥来验证B的交易签名。这些步骤确保交易有效并由B授权。比特币的一个意外部分是B的公钥在交易中使用之前不会公开。使用这个系统，比特币通过一系列交易从一个地址传递到另一个地址。可以验证链中的每个步骤以确保有效地使用比特币。请注意，交易通常可以有多个输入和输出，因此链分支到树中。比特币脚本语言你可能希望仅通过在交易中包含签名来签署比特币交易，但该过程要复杂得多。事实上，每个交易中都有一个小程序可以执行以确定交易是否有效。该程序是用Script编写的，这是一种基于堆栈的比特币脚本语言。复杂的赎回条件可以用这种语言表达。例如，托管系统可能需要三个特定用户中的两个必须签署交易才能使用它。或者可以设置各种类型的合约。Script语言非常复杂，有大约80种不同的操作码。它包括算术运算，按位运算，字符串运算，条件运算和堆栈操作。该语言还包括必要的加密操作（SHA-256，RIPEMD等）作为基元。为了确保脚本终止，该语言不包含任何循环操作。（因此，它不是Turing-complete。）但实际上，只支持几种类型的交易。为了使比特币交易有效，兑换脚本的两个部分必须成功运行。旧交易中的脚本称为scriptPubKey，新交易中的脚本称为scriptSig。要验证交易，执行scriptSig，然后执行scriptPubKey。如果脚本成功完成，则交易有效并且可以使用比特币。否则，交易无效。关键在于旧交易中的scriptPubKey定义了使用比特币的条件。新交易中的scriptSig必须提供满足条件的数据。在标准交易中，scriptSig将签名（从私钥生成）推送到堆栈，然后是公钥。接下来，执行scriptPubKey（来自源交易）以验证公钥，然后验证签名。如脚本中所述，scriptSig是：PUSHDATAsignature data and SIGHASH_ALLPUSHDATApublic key datascriptPubKey是：OP_DUPOP_HASH160PUSHDATABitcoin address (public key hash)OP_EQUALVERIFYOP_CHECKSIG执行此代码时，PUSHDATA首先将签名推送到堆栈。下一个PUSHDATA将公钥推送到堆栈。接下来，OP_DUP复制堆栈上的公钥。OP_HASH160计算公钥的160位哈希值。PUSHDATA推送所需的比特币地址。然后OP_EQUALVERIFY验证前两个堆栈值是否相等。来自新交易的公钥哈希与旧地址中的地址匹配。这证明公钥是有效的。接下来，OP_CHECKSIG检查交易的签名是否与堆栈上的公钥和签名匹配。这证明签名是有效的。签署交易我发现签署交易是手动使用比特币最困难的部分，其过程非常困难且容易出错。基本思想是使用ECDSA椭圆曲线算法和私钥生成交易的数字签名，但细节很棘手。签名过程已通过19个步骤（更多信息）进行了描述。单击下面的缩略图以获取该过程的详细图表。最大的复杂因素是签名出现在交易中间，这就提出了在签名之前如何签署交易的问题。为避免此问题，在计算签名之前，将scriptPubKey脚本从源交易复制到支出交易（即正在签名的交易）中。然后将签名转换为脚本语言中的代码，创建嵌入在交易中的scriptSig脚本。似乎在签名期间使用先前交易的scriptPubKey是出于历史原因而不是任何逻辑原因。对于具有多个输入的交易，签名甚至更复杂，因为每个输入都需要单独的签名，但我不会详细介绍。绊倒我的一步是哈希类型。在签名之前，交易具有临时附加的哈希类型常量。对于常规交易，这是SIGHASH_ALL（0x00000001）。签名后，此哈希类型将从交易结束时删除并附加到scriptSig。关于比特币协议的另一个令人讨厌的事情是签名和公钥都是512位椭圆曲线值，但它们以完全不同的方式表示：签名用DER编码编码，但公钥表示为普通字节。此外，两个值都有一个额外的字节，但位置不一致：签名后放置SIGHASH_ALL，类型04放在公钥之前。由于ECDSA算法使用随机数，因此调试签名变得更加困难。因此，每次计算时签名都不同，因此无法与已知良好的签名进行比较。更新（2014年2月）：每次签名更改的一个重要副作用是，如果重新签名交易，交易的哈希值将会更改。这称为交易可维护性。还有一些方法可以让第三方以微不足道的方式修改交易，从而改变哈希，而不是交易的意义。尽管多年来人们已经知道，但是可塑性最近在MtGox（新闻稿）中引起了很大的问题（2014年2月）。由于这些复杂情况，我花了很长时间才能使签名工作。但最终，我从签名代码中获得了所有错误，并成功签署了一项交易。这是我使用的代码片段。def makeSignedTransaction(privateKey, outputTransactionHash, sourceIndex, scriptPubKey, outputs): myTxn_forSig = (makeRawTransaction(outputTransactionHash, sourceIndex, scriptPubKey, outputs) + “01000000”) # hash code s256 = hashlib.sha256(hashlib.sha256(myTxn_forSig.decode(‘hex’)).digest()).digest() sk = ecdsa.SigningKey.from_string(privateKey.decode(‘hex’), curve=ecdsa.SECP256k1) sig = sk.sign_digest(s256, sigencode=ecdsa.util.sigencode_der) + ‘\01’ # 01 is hashtype pubKey = keyUtils.privateKeyToPublicKey(privateKey) scriptSig = utils.varstr(sig).encode(‘hex’) + utils.varstr(pubKey.decode(‘hex’)).encode(‘hex’) signed_txn = makeRawTransaction(outputTransactionHash, sourceIndex, scriptSig, outputs) verifyTxnSignature(signed_txn) return signed_txn最终的scriptSig包含签名以及源地址的公钥（1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5）。这证明我可以使用这些比特币，使交易有效。最终的scriptPubKey包含必须成功使用比特币的脚本。请注意，在使用比特币时，此脚本将在以后的某个任意时间执行。它包含以十六进制表示的目标地址（1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa），而不是Base58Check。结果是只有该地址的私钥的所有者可以使用比特币，因此该地址实际上是所有者。最后的交易一旦完成所有必要的方法，就可以组装最终的交易。privateKey = keyUtils.wifToPrivateKey(“5HusYj2b2x4nroApgfvaSfKYZhRbKFH41bVyPooymbC6KfgSXdD”) #1MMMMsigned_txn = txnUtils.makeSignedTransaction(privateKey, “81b4c832d70cb56ff957589752eb4125a4cab78a25a8fc52d6a09e5bd4404d48”, # output (prev) transaction hash 0, # sourceIndex keyUtils.addrHashToScriptPubKey(“1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5”), [[91234, #satoshis keyUtils.addrHashToScriptPubKey(“1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa”)]] ) txnUtils.verifyTxnSignature(signed_txn)print ‘SIGNED TXN’, signed_txn最终交易如下所示。这将上面的scriptSig和scriptPubKey与前面描述的unsigned交易相结合。切线：理解椭圆曲线比特币使用椭圆曲线作为签名算法的一部分。在解决费马最后定理的背景下，我之前听说过椭圆曲线，所以我很好奇它们是什么。椭圆曲线的数学很有意思，所以我会绕道而行，快速概述一下。名称椭圆曲线令人困惑：椭圆曲线不是椭圆形，看起来不像椭圆，它们与椭圆几乎没有关系。椭圆曲线是满足相当简单的方程y^2=x^3+ax+b的曲线。比特币使用称为secp256k1的特定椭圆曲线，其简单方程为y^2=x^3+7。椭圆曲线的一个重要特性是你可以使用一个简单的规则在曲线上定义点的添加：如果你在曲线中绘制一条直线并且它击中三个点A，B和C，则添加由A+定义B+C=0。由于椭圆曲线的特殊性质，以这种方式定义的加法“正常”起作用并形成一个组。如果定义了加法，则可以定义整数乘法：例如4A=A+A+A+A。使椭圆曲线在加密方面有用的原因是它可以快速进行整数乘法，但除法基本上需要强力。例如，你可以非常快速地计算诸如12345678A=Q的乘积（通过计算2的幂），但是如果你只知道A和Q求解nA=Q很难。在椭圆曲线加密中，密码12345678将是私钥，曲线上的点Q将是公钥。在密码学中，坐标不是在曲线上使用实值点，而是以模数为模的整数。椭圆曲线的一个令人惊讶的特性是，无论使用实数还是模运算，数学运算都非常相似。因此，比特币的椭圆曲线看起来不像上面的图片，而是一个随机的256位点混乱（想象一个大的灰色方块点）。椭圆曲线数字签名算法（ECDSA）采用消息哈希，然后使用消息，私钥和随机数进行一些简单的椭圆曲线算法，以在曲线上生成给出签名的新点。拥有公钥，消息和签名的任何人都可以执行一些简单的椭圆曲线算法来验证签名是否有效。因此，只有具有私钥的人才能签署消息，但是具有公钥的任何人都可以验证该消息。有关椭圆曲线的更多信息，请参阅参考文献。将我的交易发送到p2p网络留下椭圆曲线，此时我创建了一个交易并签名。下一步是将其发送到点对点网络，在那里它将被矿工接收并合并到一个块中。如何找到同行使用p2p网络的第一步是找到一个对等体。每当有人运行客户端时，对等体列表每隔几秒就会更改一次。一旦节点连接到对等节点，它们就会在发现新对等体时通过交换addr消息来共享新对等体。因此，新同伴迅速通过该系统传播。然而，关于如何找到第一个同伴，有一个鸡与蛋的问题。比特币客户通过几种方法解决了这个问题。几个可靠的对等体在DNS中以bitseed.xf2.org的名称注册。通过执行nslookup，客户端获取这些对等端的IP地址，并希望其中一个可以工作。如果这不起作用，则将对等体的种子列表硬编码到客户端中。当普通用户启动和停止比特币客户端时，同行进入和离开网络，因此客户端有大量的营业额。我使用的客户现在不太可能正常运营，所以如果你想做实验，你需要找到新的同行。 你可能需要尝试一堆才能找到有效的方法。和同龄人交谈一旦我获得了工作对等体的地址，下一步就是将我的交易发送到对等网络。使用点对点协议非常简单。我在端口8333上打开了与任意对等方的TCP连接，开始发送消息，并依次接收消息。 比特币点对点协议非常宽容;即使我完全搞砸了请求，同行也会保持沟通。重要提示：正如一些人所指出的，如果你想进行实验，你应该使用比特币测试网，这可以让你试验“虚假”的比特币，因为如果你搞砸了真正的网络，很容易丢失你的宝贵的比特币。（例如，如果你忘记了交易中的更改地址，那么多余的比特币将作为费用交给矿工。）但我想我会使用真正的比特币网络并冒险使用价值1.00美元的比特币。该协议由大约24种不同的消息类型组成。每条消息都是一个相当简单的二进制blob，包含一个ASCII命令名和一个适合该命令的二进制有效负载。该协议在比特币维基上有详细记录 。连接到对等方的第一步是通过交换版本消息来建立连接。首先，我发送一个版本消息，其中包含我的协议版本号，地址和其他一些内容。对等体发回其版本消息。在此之后，节点应该用verack消息确认版本消息。（正如我所提到的，该协议是宽容的 - 即使我跳过了那个行列，一切正常。）生成版本消息并不是完全无关紧要的，因为它有一堆字段，但它可以用几行Python创建。下面的makeMessage根据幻数，命令名和有效负载构建一个任意的对等消息。getVersionMessage通过将各个字段打包在一起来为版本消息创建有效负载。magic = 0xd9b4bef9def makeMessage(magic, command, payload): checksum = hashlib.sha256(hashlib.sha256(payload).digest()).digest()[0:4] return struct.pack(‘L12sL4s’, magic, command, len(payload), checksum) + payloaddef getVersionMsg(): version = 60002 services = 1 timestamp = int(time.time()) addr_me = utils.netaddr(socket.inet_aton(“127.0.0.1”), 8333) addr_you = utils.netaddr(socket.inet_aton(“127.0.0.1”), 8333) nonce = random.getrandbits(64) sub_version_num = utils.varstr(’’) start_height = 0 payload = struct.pack(’<LQQ26s26sQsL’, version, services, timestamp, addr_me, addr_you, nonce, sub_version_num, start_height) return makeMessage(magic, ‘version’, payload)发送交易：tx我使用下面的精简Python脚本将交易发送到对等网络。该脚本发送版本消息，接收（并忽略）对等方的版本和维拉消息，然后将该交易作为tx消息发送。十六进制字符串是我之前创建的交易。def getTxMsg(payload): return makeMessage(magic, ’tx’, payload)sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)sock.connect((“97.88.151.164”, 8333))sock.send(msgUtils.getVersionMsg())sock.recv(1000) # receive versionsock.recv(1000) # receive veracksock.send(msgUtils.getTxMsg(“0100000001484d40d45b9ea0d652fca8258ab7caa42541eb52975857f96fb50cd732c8b481000000008a47304402202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168233e8201410414e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee751310f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcdffffffff0162640100000000001976a914c8e90996c7c6080ee06284600c684ed904d14c5c88ac00000000”.decode(‘hex’)))以下屏幕截图显示了如何在Wireshark网络分析程序中发送我的交易。我编写了Python脚本来处理比特币网络流量，但为了简单起见，我将在这里使用Wireshark。“tx”消息类型在ASCII转储中可见，在我的交易开始的下一行（01 00 …）后面。为了监视我的交易的进度，我有一个套接字打开给另一个随机对等体。发送我的交易五秒后，另一个对等体发送了一条tx消息，其中包含我刚刚发送的交易的哈希值。因此，我的交易只需几秒钟即可在对等网络或至少部分网络中传递。胜利：我的交易被开采了在将我的交易发送到对等网络后，我需要等待它才能获得胜利。十分钟后，我的脚本收到一条带有新块的inv消息（参见下面的Wireshark描述）。检查此块显示它包含我的交易，证明我的交易有效。我还可以通过查看我的比特币钱包和在线查询来验证此交易是否成功。因此，经过大量的努力，我成功地手动创建了一个交易并让它被系统接受。（不用说，我的前几次交易尝试都没有成功，我的错误交易消失在网络中，永远不会被再次看到。）我的交易是由大型GHash.IO矿池开采的，块为#279068，哈希为0000000000000001a27b1d6eb8c405410398ece796e742da3b3e35363c2219ee。（哈希在上面的inv消息中反转：ee19…）请注意，哈希以大量零开始——在quintillion值中找到这样的字面意思是使挖掘变得如此困难的原因。这个特殊的块包含462个交易，其中我的交易只有一个。为了开采这个区块，矿工们获得了25比特币的奖励，总费用为0.104比特币，分别约为19,000美元和80美元。我支付了0.0001比特币的费用，约占我交易的8美分或10%。挖掘过程非常有趣，但我将把它留给以后的文章。结论使用原始的比特币协议比我预期的要困难，但我一路上学到了很多关于比特币的知识，我希望你也做到了。我的代码纯粹是为了演示——如果你真的想通过Python使用比特币，请使用真正的库而不是我的代码。======================================================================分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程：EOS教程，本课程帮助你快速入门EOS区块链去中心化应用的开发，内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点，最后综合运用各知识点完成一个便签DApp的开发。java以太坊开发教程，主要是针对java和android程序员进行区块链以太坊开发的web3j详解。python以太坊，主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。php以太坊，主要是介绍使用php进行智能合约开发交互，进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。以太坊入门教程，主要介绍智能合约与dapp应用开发，适合入门。以太坊开发进阶教程，主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战，适合进阶。C#以太坊，主要讲解如何使用C#开发基于.Net的以太坊应用，包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。java比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Java代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Java工程师不可多得的比特币开发学习课程。php比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Php代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Php工程师不可多得的比特币开发学习课程。tendermint区块链开发详解，本课程适合希望使用tendermint进行区块链开发的工程师，课程内容即包括tendermint应用开发模型中的核心概念，例如ABCI接口、默克尔树、多版本状态库等，也包括代币发行等丰富的实操代码，是go语言工程师快速入门区块链开发的最佳选择。汇智网原创翻译，转载请标明出处。这里是原文如何使用原始比特币协议 ...

在近期发布的《2018年上半年中国移动互联网行业发展分析报告》中提出，在上半年中国移动互联网关键字TOP1是“安全”，安全已成为中国移动互联网企业存亡生命线。作为平台，首先要保证输出内容的安全，其次要保证用户的人身财产安全及数据安全。安全，为立“身”之本。在过去二十多年中，伴随着移动互联网的发展，游戏行业经历很大的变化——不仅仅是从技术上的革新，游戏的实现能力更是有了飞跃的发展，但是在移动游戏逐渐成为大众休闲娱乐的主流方式的背后，其安全正受到网络黑产的巨大威胁。移动游戏发展迅猛，安全问题如影随形 据相关数据显示，截止到2018年3季度，全球移动互联网用户已超过30亿，欧美、东亚等区域渗透率近80%。从3季度基于移动互联网应用月新增占比分布数据看，游戏行业占比位居第二，且主流手机游戏应用MAU同比增长趋势明显。但是，随着硬件与开发技术的成熟相继发展成型，游戏行业安全问题也随之出现，外挂工具、系统功能漏洞、服务器宕机漏洞等问题频发，也将大幅影响游戏内平衡，使用户体验下降。可以说，无论是移动应用还是游戏，发生安全问题就如同打开“潘多拉魔盒”，不但可能危害用户切身利益，也同样会造成企业的损失。与此同时还会发生企业信誉危机，品牌口碑大幅下滑等一系列问题。在腾讯安全云鼎实验室于近日发布《2018年游戏行业安全监测报告及五大攻击趋势》的数据显示，目前游戏行业安全威胁主要包括账号类攻击、DDoS攻击、外挂和其他四大类。1. 帐号类攻击针对游戏行业的帐号类攻击，月均在数亿次/月，且持续平稳，具有长期持续性攻击的特征。（1）攻击类型分布在针对帐号的攻击中，大部分的帐号扫描其实也是为了撞库攻击做准备，少部分是基于历史密码的登录尝试。因此，在帐号安全侧，撞库相关攻击实际占据了80%以上的份额。2. DDoS 攻击 从2018年情况统计中，游戏行业仍为DDoS 攻击主要目标，其中移动 Web 游戏被攻击数量明显增加。从被攻击游戏分类看，端游与手游依然占比最大。3. 外挂2018年主要外挂集中在手游的吃鸡类游戏上，其中外挂热度排名前四的吃鸡类手游占据了超过60%的关注度，加上 PC 端的射击类游戏，射击类外挂已然占据了70%以上。4. 其他 其他攻击还包括主要集中在 App Store 平台的代充值类问题，比如：外币汇率差、黑卡和盗刷信用卡等。移动游戏行业发展，需与游戏安全比翼齐飞 移动游戏安全问题逐渐泛滥已经引起了政府监管部门的关注，政府监管部门已明显放慢了版号审批速度，实施网络游戏总量调控，同时也采取了一系列相应措施：2017年12月，中共中央宣传部、中央网信办、工业和信息化部、教育部、公安部、文化部、国家工商总局、国家新闻出版广电总局联合印发《关于严格规范网络游戏市场管理的意见》(以下简称《意见》)，部署对网络游戏违法违规行为和不良内容进行集中整治。《意见》中明确提出：“网络游戏系统安全、用户信息安全问题较为突出，个人信息泄露、账号非法交易现象较为普遍。同时，管理体制机制与市场发展还不完全匹配，相关法律法规还不够健全，方式手段还不够完善，纠错惩戒不足以形成震慑。”2018年2月5日下午，浦东网安支队召开浦东地区游戏行业网络安全工作会，会议就目前网游行业发展所导致的文化内容缺失等突出问题为背景，向浦东地区的114家网络游戏企业下发《网络游戏企业基础排摸调研表》，并开展法律法规教育，要求各单位核实并上报本单位的信息安全问题。与此同时，全国很多监管部门也在加紧行动，全面排查，加紧规范整治。在2018年12月21日举行的中国游戏产业年会上，中宣部出版局有关人士表示：“首批送审游戏已经完成审核，正在抓紧核发版号”，说明暂停已久的移动游戏审批重新启动，移动游戏行业又将迎来新的春天。而未来，移动游戏的健康发展更需要安全系统的有力加持。移动游戏主要安全攻击分析移动游戏可分为单机游戏和网络游戏两大类，基于不同类别游戏特点进行分析：1.单机游戏这类游戏所有的数据基本都在本地，面临的分析主要有内购破解，二次打包，游戏修改器等威胁。因为数据基本都在本地，攻击者可以修改本地数据达到一些非法的目的，比如：修改生命值，增加金钱，修改伤害值等。还有一些抄袭者将游戏彻底分析，或者重新二次代码，只修改游戏里面的原有包名，和游戏人物角色ui和名称，可以快速开发一款同类产品，减少开发周期。还有就是直接盗用，修改支付链接，转换为自己的，并将付费额度修改为比正版更低的价格。2.网络游戏这类游戏主要的数据是和服务器进行交互，有些战斗数据计算可能在本地或者是服务器，应对本地计算的，建议放到服务器计算，这样安全性更高。主要的威胁有：外挂，私服，第三方抄袭等。外挂：可以通过分析游戏的核心数据，分析游戏的内部代码达到一些非法操作，比如脱机挂可以自动注册游戏，进行游戏通关操作、刷金币、刷等级等；还有通过外挂可以加速游戏运行，缩短游戏打斗。私服：这种情况是通过破解游戏和服务器的通信协议自建服务器，将游戏网络地址给为自建服务器地址。第三方抄袭：破解游戏后，分析游戏的数值数据、关卡配置等一系列的数据信息。若为网络数据则通过抓包等手段进行分析，开发者只需要修改ui等手段即可以快速出一款同类游戏，减少了策划等工作。造成安全问题的技术实现分析：1.内购破解：通过暴力破解方式，绕过/破解支付校验代码，支付框架、sdk破解，造成收入严重受损。2.修改内存通过内存注入、动态调试、内存dump等操作恶意篡改游戏内容，造成游戏平衡性下降。3.二次打包篡改游戏代码、更换游戏logo、皮肤、包名，篡改后的游戏，造成扣费、流量损耗、弹广告等等，造成公司名义受损。4.游戏修改器游戏修改器对几乎所有的游戏都会造成严重破坏，修改游戏属性值，严重破坏游戏平衡，付费环节变得没有任何作用，收入变低，用户兴趣低，用户量损失。5.核心技术、数据信息丢失通过破解方式，获取游戏核心代码，对公司自主产权造成严重损害，游戏数据信息丢失、玩家个人信息数据泄露。移动游戏安全解决方案解析 1.Java代码vmp加密对dex文件进行native指令化转化，并且以native方式还原到安卓内存中，即使使用dump手段dump出当前部分代码，也是经过native处理过的代码，不会还原成APP源代码。2.动态调试保护（1）防动态注入防注入保护，能防止APP运行时通过注入的方式获取APP隐私数据、使用hook等方式劫持APP的正常运行流程等。当加固后的APP检测到注入时，APP会自动退出运行。（2）防动态调试反调试机制能够拒绝调试工具的附加操作，阻止调试器对移动应用调试分析其业务逻辑代码，一旦被加固的程序检测到有如gdb等调试操作将自动退出运行。（3）防内存dump防内存dump保护，能有效阻止gdb dump等操作，同时因为代码采用函数体分离方式和native化保护，代码都是以单个函数还原到内存中，而内存中的代码也是经过native处理，及时dump出当前代码片段，也是经过native方式处理后的代码，不会还原成源代码。3.防二次打包对签名做完整性校验保护，一旦更改签名文件，程序将不会再次运行。4.So源码混淆对SO文件做加密和自定义加载处理，除此之外还会对SO文件中字符串加密和代码混淆处理，层层防止攻击者提取SO文件和对其二进制代码做反编译和反汇编处理。对Objective-C、C、C++编译后的Native代码进行代码混淆处理，被混淆过后的代码中存在多余代码、怪癖语法、冗余逻辑判断，冗余函数调用等难以阅读和理解的代码，结合字符串加密和反调试机制等功能，让攻击者无法反编译，从而有效的保护源代码安全。5.代码虚拟化保护采用基于LLVM编译器中间层实现的虚拟化编译器，可通过虚拟CPU解释器以及虚拟IR指令，将原始CPU指令进行加密转换处理为只能由虚拟解释器解释执行的虚拟指令，能够完全隐藏函数代码逻辑，以及函数及变量之间的依赖关系。6.其他安全建议iOS安全建议，为了防止在Android端无法分析出协议，但是可以通过iOS端分析的情况发生，建议iOS端也做安全加密操作，iOS端源码混淆功能与so文件源码混淆功能相同，字符串加密、代码结构逻辑混淆、指令替换、控制流平坦化，虚假控制流等。实例解构 几维安全通过长期研究开发，形成了专有技术KiwiVM虚拟化保护方案，实现CPU指令虚拟化，对手游的核心代码进行安全编译、生成受保护的安全模块，从而避免因破解造成的安全风险。以几维安全为某移动游戏企业提供的安全加固案例为例进行解构：1、基于公司现状进行安全风险分析，梳理出该公司的安全加固需求：（1）手游基于Unity3d引擎开发，核心DLL文件存在被逆向破解的风险；（2）不具备正版校验机制，伪冒、盗版手游影响正版手游的正常运营；（3）游戏修改器、脱机挂破坏游戏的公平性，付费用户逐渐流失。2、结合该公司的特点，拟定端到端的整体安全防护方案：3．以整体安全体系架构为基础，根据需求进行单产品或产品组合部署如：在该案例中提供《KiwiVM虚拟机》和《Unity3D手游加密》方案，保护企业核心代码，保障手游正常的运营与推广。（1）提供KiwiVM虚拟化服务KiwiVM是基于Clang编译器扩展实现的VM虚拟机编译器, 在编译时直接对指定的函数［代码］实施虚拟化处理。其加密过程不可逆，攻击者无法还原代码，分析核心业务逻辑。可帮助中大型企业在通信、支付、算法、核心技术等模块进行深度加密，避免因逆向破解问题造成的经济损失。（2）Unity3D手游加密服务Unity3D手游加固服务是在APP安全加固的基础之上，针对Unity3D手游，扩展了函数级［或整体级］的DLL文件加密功能，避免DLL文件被 .NET Reflector 等破解工具提取C#源代码。与DEX加密、防二次打包、内存保护、反调试、防系统加速挂等功能配合形成一套完整的Unity3D手游加密方案。登录移动安全管理平台即可使用。DLL函数级加密为企业版，其算法有几十种可供选择，同时对这些加密算法都有高强度的加密保护，攻击者无法通过Dump内存数据来窃取C#源代码。结语 移动游戏安全系统价值在于维护公平的游戏环境、保护玩家财产、提高用户体验感。千锤百炼，锻造移动游戏安全防护黄金铠甲，为企业树立可信品牌，使用户安心驰骋在手游疆场，助力游戏行业在移动互联网大发展浪潮中更蓬勃的发展。

概述：点播转码目前涉及用户上传自动触发转码、通过SubmitTranscodeJobs接口触发转码等方式，会出现用户转码失败的情况，这当中有用户源片的问题、也有用户设置转码参数的原因以及相关资源性数据授权限制问题导致，本文主要提供点播转码常见的问题排查及处理方式。HLS标准加密问题排查SubmitTranscodeJobs接口错误提示：KeyNotFound：出现这种错误提示一般都是使用的加密Service Key 和视频不在同一个区域，例如：华东2的视频，必须使用华东2的KMS生成秘钥。NoSuchResource：出现这种错误通常代表用户的某种的资源缺失，可以结合message进行排查，如下所示：1、“can not find cross service token” ：表示用户没有通过RAM授权点播操作用户的KMS导致，需要用户先授权。 2、“can not find customer encrypt master key”：表示在用户对应区域的KMS中没有拿到响应的加密Service key，可以在神农鼎生成对应区域的Service Key。 3、“can not find customer encrypt info”：表示用户传递的密文秘钥不是使用KMS生成或者秘钥生成和视频存储不在同一个区域，需要用户在视频相应区域生成加密秘钥。 4、“can not find customer plaintext”：表示用户生成的秘钥解密不到明文秘钥，需要用户使用GenerateDataKey生成加密秘钥。 5、“The specified resource Template does not exist”：表示视频对应区域的转码模板数据不存在，这种问题通常是模板添加或者更新接口异常导致，可以联系点播后台进行数据订正。其他常见问题：文件未加密：生成的文件未加密，一般都是由于转码模板在设置的时候没有选择HLS加密选项(标准加密、私有加密必须要勾选)加密转码失败：视频标准加密失败，一般都是由于用户在调用GenerateDataKey生成的秘钥是非AES_128位的，或者秘钥使用自定义字符串生成解密失败：通常HLS标准加密成功，说明秘钥是没问题的，那么解密失败通常是由于解密接口直接将名称秘钥返回，实际应该是将名称秘钥进行base64decode解码之后返回MtsHlsUriToken参数重写失效：可能存在以下两点问题1、对应的域名没有开通CDN的MtsHlsUriToken参数重写功能，需要到CDN神农鼎设置。 2、域名开启了鉴权，MtsHlsUriToken参数重写和鉴权功能是互斥的。转码失败问题排查：转封装(原画)失败：通常都是由于格式支持问题导致，例如：wmv、rmvb等格式不支持装封装成mp4；mpeg4不能转封装成m3u8条件转码导致转码失败：查看用户是否开启对应的条件转码，如果开启则表模板设置的分辨率、码率是否大于源片的分辨率或者码率，如果大于则模板设置是按照源片转码还是不转码，不转码则会以失败的结果返回，这种是正常的转码处理步骤，可建议用户修改条件转码阈值或者移除条件转码限制。视频转码失败原因及排查步骤：1、查看源片文件大小是否为0，这种视频通常是没有上传成功但是OSS错误的通知底层触发转码导致。2、点播神农鼎查看源片地址看是否可以播放，不可播放通常转码都会失败，说明源片存在问题3、使用ffprobe -show_streams -print_format json -i “文件地址"查看源片是否存在多个音频流，目前转码还不能处理多音轨源片4、使用ffprobe -show_streams -print_format json -i “文件地址” 或者ffprobe -show_frames -print_format -i “文件地址” 查看文件的音视频流、帧信息，如果存在红色异常提示，基本上可以确定源片封装参数存在问题，例如：源片的NAL数据问题源片流数据有问题源片的音视频Codec封装异常：Codec 为data或者binary类型转码成功但文件异常：转码视频变形：原因是用户设置转码模板同时设置了宽和高，这样会导致源片的画面比例如果和设置的宽高比例不一致，就发生了形变，解决办法是只设置宽或者高，保持另一边按照源片的画面比例等比输出。视频转码后时间变长：这种视频一般都是由于源片的pkt_pts_time显示时间过大导致，可以通过ffprobe -show_frames -print_format json -i “源文件地址"查看pkt_pts_time是否异常，一般都是大于源片的真实时长，正常的pkt_pts_time是均匀递增，最大为视频总时长。视频转封装成m3u8的ts分片大小差别大：一般都是源片的关键帧分布不均匀导致的，可以通过查看ffprobe -show_frames -print_format json -i “源文件地址"命令查看帧信息，看key_frame=1的帧信息中pakt_pts_time是否均匀递增，如果非均匀一般会导致转封装ts切片不均匀。直播转点播有音频无画面：一般都是用户侧推流的前面几个ts分片全是音频无视频画面导致，而底层转码只会抓取前面几个ts分片的编码信息，如果前面几个ts分片无视频流，则转码器只会读取音频流，从而导致整个视频输出无画面。其他转码任务卡住，一直处于转码中:通常发生在直播转点播录制的视频，这种视频限于推流端配置的问题，导致pts_time非均匀增加，而是跳变，这种情况会导致底层转码ffmpeg卡住，无任何转码结果返回，这种视频通常建议用户排查推流端设置问题。