便宜VPS网什么是签名验签服务器？
渔翁通用型签名验签服务器严格按照国家密码管理局GM/T 0029-2014《签名验签服务器技术规范》等技术规范进行设计，产品已取得国家密码管理局商用密码检测中心颁发的商用密码产品认证证书，支持国家密码管理局认可的密码算法，能够为各类信息系统提供数字签名和验签、基于数字证书的身份认证、基于数字证书的加解密等安全保护⌄保证关键业务信息的真实性、完整性和不可否认性。产品可应用于电子商务、CA认证、网上银行、证券交易、司法公证等信息系统的服务端，提供高安全强度、高效率、高可靠性的密码服务。
破解“贪吃蛇大作战”的签名信息服务端验证机制
Android安全交流群：478084054
第一次尝试做一些简单的逆向分析，内容比较简单，高手们莫见笑。
“贪吃蛇大作战”这个游戏最近玩的人挺多，我也在玩。5分钟限时版，最好成绩也就3000多。
我分析的版本是v2.0.1：
经过修改，玩了一把5分钟限时赛：长度69224，击杀1456。
将原包重新签名，安装到手机上，一直提示网络无法连接，原包没有问题。这里很明显是将签名信息上传到了服务器端，在服务器端进行了签名校验，校验失败则断开与此客户端的连接。
写一个小程序进行注入（利用ptrace），对一些关键函数进行hook，比如libc.so的fopen函数。
在hook_entry中，对libc.so的fopen作inline hook，监测一下程序都打开了哪些文件。
我本意是想看看，它是否会在运行时直接去读取apk包，自己解析其中的与签名信息相关的文件。结果是没有，但发现它一直在读cmdline文件，猜测可能是在作反调试（未去证实，因为后面的分析和修改并未借助动态调试）。
这里说一下，假设它是自己打开apk文件，从中读取与签名相关的文件，提取签名信息。那么我们可以在某个位置放一个原包，然后hook关键函数，将其读取的文件路径修改为原包位置，即可绕过这种签名校验。
举一反三，这种方式也可以绕过大部分反调试措施。比如常见的检测traceid是否非0的反调方式，我们可以hook fopen/open，然后在它要读取该文件之前先读取该文件，并将其traceid重新修改为0，并将其写到sd卡某个目录下，再将打开文件的位置重定向到该文件，那它就检测不到ptrace了。
还有一些anti-hook机制，大概思路是校验本地文件的数据和加载到内存中的数据是否一致。通过类似方式也可以轻松绕过，一句话，因为我们可以先注入，先完成hook，先做各种Anti-anti。
因为它没有在运行时直接fopen/open apk文件，所以考虑应该还是通过调用系统api读取的签名信息。
将原包解压，发现只有两个so，其中libweibosdkcore.so看起来是微博sdk。将另一个libJustATest.so拖到IDA中看一下，没加壳，并且只看到xxx_getATestString这么一个有用的导出函数，从名字上看，很可能就是获取上传到服务器端的校验字符串。
跳转到该方法，f5，进行一些简单的参数名和参数类型以及函数调用的修正。发现它里面进行了一大通的各种字符串的拼接，最后将该字符串返回（根据之前的猜测，该字符串可能就是发送给服务端的校验字符串）。
发现里面调用了java层com.wepie.snake.helper.update.QiniuEtagUtil类的getSignString函数。用AndroidKiller反编译一下APK包（该APK没有作任何防反编译的措施，dex也没加壳），找到getSignString函数。
没错，就是在这里调用系统API获取的签名（其实，我们可以一开始就全局搜索某些关键API，来定位获取签名的位置）。
借助xposed hook getSignString方法，将正确的签名字符串通过日志打印出来。
正确的签名字符串是（作了MD5计算后的结果）：678a930b9829b54a44f92a840916f7d1
剩下的工作就简单了，修改smali，将getSignString的返回结果固定为上面的这个正确的签名字符串。
重新编译、打包、签名、安装，发现用新签名的APK包已经可以正常使用了。
其实破解签名校验之后，基本上是想改什么改什么了，因为原包没有做任何的加壳和混淆的工作。比如，看看下面这个类，应该知道怎么下手了吧（修改的时候注意一下，它里面好像有一些简单的数据合理性校验之类的东西，我没细看）。
最后，大家学习就好，别做什么破坏，也别释放出什么破解版之类的东西。初次尝试一点简单的逆向分析，大牛们绕过吧。
附：我认为现在so端最有用的加固措施是llvm混淆，因为普通加解密壳从机制上来说比较容易脱掉。dex端已经出现了解释器壳（伪vmp），纯粹的类抽取的话，通过自定义rom（定制dalvik或art，遍历class_def加载并初始化，然后dump…）也可以脱掉大部分的。
API接口入门（二）：API接口的签名验签和加解密原理
本文目录：
API接口为什么要签名加密？
API接口如何加密？
一、API接口为什么要签名加密？
想象一个场景：一位许久不见的好兄弟，突然在微信里面跟你说“兄弟，借我1万应急呗”，你会怎么反应？
我想大部分人马上的反应就是：是不是被盗号了？他是本人吗？
实际上这是我们日常生活中常见的通讯行为，系统间调用API和传输数据的过程无异于你和朋友间的微信沟通，所有处于开放环境的数据传输都是可以被截取，甚至被篡改的。因而数据传输存在着极大的危险，所以必须加密。
加密核心解决两个问题：
你是本人吗？（签名验签）
你传过来的信息是对的吗？（加密解密）
二、API接口如何签名验签和加密解密？
古代人写信通过邮差传信，路途遥远，他们为了避免重要的内容被发现，决定用密文来写信，比如我想表达“八百标兵上北坡”，我写成800north，并且收件人也知道怎么阅读这份信息，即使路上的人截取偷看了，也看不懂你们在说的什么意思。同时我在文末签上我的字迹，在盒子里放上我的信物（比如一片羽毛等等），这样收件人也就知道这份信是我寄出的了。
这被称为“对称性密码”，也就是加密的人用A方式加密，解密的人用A方式解密，有什么缺点呢？
如果你经常传输，这就很容易被发现了密码规律，比如我很快就知道你寄信都会带上一片羽毛，那我以后也可以搞一片羽毛来冒充你了。加上，如果我要给很多人寄信，我就要跟每个人告诉我的加密方式，说不准有一个卧底就把你的加密方式出卖了。
因为互联网传输的对接方数量和频率非常高，显然搞个对称性密码是不安全的。于是，基于对称性密码延伸出“非对称密码”的概念。
1. 公私钥——签名验签及加解密原理
通俗的解释：A要给B发信息，B先把一个箱子给A，A收到之后把信放进箱子，然后上锁，上锁了之后A自己也打不开，取不出来了，因为钥匙在B的手里，这样即使路上被截取了，别人也打不开箱子看里面的信息，最后B就能安全地收到A发的信了，并且信息没有泄露。
现在我们以一个单向的A发信息给B的场景进行深入了解公私钥工作原理。
发送者和接收者都有2套加解密的方法，而且他们把其中一套加密方法a和解密方法b都公开（虚线标黑）；
这里提到的加解密，因为密码学过于深奥，无法解释。大家需默认加密方法是不能反推出解密方法的，解密方法是不能反推出加密方法的。a加密就必须a解密，b加密就必须b解密；
现在A需要向B发送一条信息，因为信息的内容很重要，他就用接收者B的加密方法c进行加密，这样只有B自己的解密方法c才能解开，任何人获取了都解开不了，包括A自己也解不开；
在A向B发送信息的同时，需要带上自己的签名，这个时候A用自己才知道的加密方法b进行加密，因为任何人都知道解密方法b，所以任何人都可以看到A的签字，也就是任何人都知道这条是A发出来的信息，但因为签名不是不能公开的信息，所以被解密了也没有关系。
总结：
（1）签名会被任何人获取，但因为签名内容不涉及核心内容，被获取破解是OK的。
（2）重要内容只能接收方解密，任何人获取了都无法解密。
（3）接收者B只有验证签名者是A的信息，才会执行接下来的程序。阿猫阿狗发来的信息不予执行。
捣局者C可能的情况：
（1）他获取到这条信息是A发出的，但看不明白加密的内容。
（2）他可以也用接受者B的加密方法c向接收者B发信息，但他无法冒充发送者A的签名，所以B不会接受C的请求。
（2）公私钥的非对称加密+session key对称加密
2. 公私钥的非对称加密+session key对称加密
上一小节解释的公私钥加密是标准和安全的，但因为这类非对称加密对系统运算的需求比较大，在保证安全的前提下，还是尽量希望提升程序响应的时效。所以目前主流应用的另一种加密方式是公私钥的非对称加密+session key对称加密。
当A向B发送信息的时候，不需要用到B的公私钥。
A用自己的加密方法b加密签名和一条空信息，因为信息无关重要，被破解了也没关系，B利用解密方法b验证了是A发来的信息。
这个时候，接收者B用发送者A的加密方法a，加密一个有时效的加密方法给A（相当于告诉A，这2个小时，我们用这个暗号进行沟通），因为只有A有解密方法，所以别人获取了也不能知道session key是什么。
A接收到session key了以后，A用这种有时效的加密函数发送重要信息，签名仍用加密方法b加密，B用同样一个加密函数解密（实际上变成了对称加密，大家都用同样的方式加解密）
2小时后，再重复第2步，更新加密方法。
3. 总结
（1）当B向A发出临时有效的加密方法之后，通讯的过程变为了对称加密；
（2）这类加密方式的核心是时效性，必须在短时间内更新，否则固定的规律容易被获取破解。
捣局者C可能的情况：
（1）他获取到B发出的session key的加密文件，无法破解session key是什么。因为解密方法在A手上；
（2）通过各种手段，C破解出session key的加解密方法，但因为时效已到，session key更新，C徒劳无功；
（3）C在时效内破解出session key，但无法冒充A的签名。
以上是2种常见的加解密方式，每个开放平台会在概述中最开始介绍API调用的安全加解密方法，这是每个对接过程中必须的准备流程，如微信企业平台在概述中就已介绍利用第2种方法（企业微信命名为access_token）进行加解密传输。
三、最后
以上就是API签名验签和加解密的基本原理，接下来我会继续更新API的请求方式等问题，同时以企业微信，微信开放平台等大型开放平台的业务解释各平台支持的现有功能。
综上，水平有限，如有纰漏，敬请指出。
中金国信签名验签服务器dn怎么查看
1、首先查看中金国信签名验签服务器dn在Internet Explorer，在Internet Explorer的菜单上，单击 “工具”菜单中的 “Internet选项”。选取“内容”选项卡，点击“证书”按钮来查看读者信任的当前证书的列表。
2、其次点击“个人”选项卡可以查看已经申请的个人数字证书，选定要查看的个人数字证书。
3、最后然后单击 “查看” 按钮，可以查看证书的详细信息。
视频安全密钥服务系统可以应用在哪些场景呢？
渔翁信息视频安全密钥服务系统可以应用在以下场景：
1.交通视频监控系统
交通视频监控系统遍布机场⌄铁路、港口、码头、汽车站、学校、医院、大型商贸中心、展览场馆、体育场所等，是保障城市交通运转安全的重要手段，对于加强安全防范和交通管理至关重要。根据GB 35114《公共安全视频监控联网信息安全技术要求》标准要求，视频监控系统需要应用密码技术，实现视频数据的真实性、完整性、机密性和抗抵赖性保护。
2.雪亮工程
雪亮项目是以县、乡、村级综合管理中心为指挥平台，以公安视频监控网络应用为依托的“群众治安防控工程”。
通过视频安全密钥服务系统可保障雪亮工程中公共安全视频监控更加可信可靠，实现视频数据的真实性、完整性、机密性和抗抵赖性保护。
3.平安城市
平安城市通过在城市重点道路、公共场所、要害部门、公共交通系统、社会和居民小区等构建视频监控系统，同时配合报入侵报警系统、出入口控制系统、广播系统等形成满足城市治安管理等需求的安全防范综合体。
视频安全密钥服务系统可应用于平安城市视频监控领域，实现实体身份真实、信令真实可靠、视频数据安全，最终实现符合GB 35114强制性国家标准。
视频安全密钥服务系统应用场景部署图如下：
图1-3 渔翁信息视频安全密钥服务系统应用场景
视频采集区
前端视频摄像头内置硬件密码模块，作为证书及密钥的载体，同时也负责视频加密密钥VEK的生成、以及加解密运算服务。
视频监控中心
1）部署视频安全密钥服务系统、服务器密码机、签名验签服务器，其中视频安全密钥服务系统来进行具有用户和设备身份证书制发功能,为视频监控安全管理平台提供证书签发、查询和验证等服务；服务器密码机用来进行视频流数据的加密、解密等密码运算；签名验签服务器用来进行视频流的签名、验签等服务。
2）各视频监控平台的服务器内置硬件密码模块，用来做证书及密钥的载体，同时进行基本的加解密运算功能。
3）视频监控客户端配备智能密码钥匙，用于管理人员登录使用。
科普：国产密码算法
密码学(cryptography)： 通过将信息编码使其不可读，从而达到安全性。
算法 ：取一个输入文本，产生一个输出文本。
加密算法 ：发送方进行加密的算法。
解密算法 ：接收方进行解密的算法。
对称密钥加密 (Symmetric Key Cryptography)：加密与解密使用相同密钥。
非对称密钥加密 (Asymmetric Key Cryptography)：加密与解密使用不同密钥。
密钥对 ：在非对称加密技术中，有两种密钥，分为私钥和公钥，私钥是密钥对所有者持有，不可公布，公钥是密钥对持有者公布给他人的。
公钥 ：公钥用来给数据加密，用公钥加密的数据只能使用私钥解密。
私钥 ：如上，用来解密公钥加密的数据。
摘要 ：对需要传输的文本，做一个HASH计算。
签名 ：使用私钥对需要传输的文本的摘要进行加密，得到的密文即被称为该次传输过程的签名。
密码协议是指两个或两个以上的参与者为了达到某种特定目的而采取的一系列步骤。规定了一系列有序执行的步骤，必须依次执行。必须有两个或两个以上的参与者，有明确的目的。参与者都必须了解、同意并遵循这些步骤。
常见的密码协议包括IPSEC VPN 协议、SSL VPN 协议、密钥交换协议等。
密码是指描述密码处理过程的一组运算规则或规程，一般是指基于复杂数学问题设计的一组运算，其基本原理基于数学难题、可证明计算、计算复杂度等。主要包括:对称密码、公钥密码、杂凑算法、随机数生成。
在对称加密算法中，加密使用的密钥和解密使用的密钥是相同的，加密和解密都是使用同一个密钥，不区分公钥和私钥。
通信双方采用相同的密钥来加解密会话内容，即一段待加密内容，经过同一个密钥的两次对称加密后，与原来的结果一样，具有加解密速度快和安全强度高的优点。
国际算法:DES、AES。
国产算法:SM1、SM4、SM7。
非对称加解密算法又称为 公钥密码 ，其密钥是成对出现的。双方通信时，首先要将密钥对中的一个密钥传给对方，这个密钥可以在不安全的信道中传输；传输数据时，先使用自己持有的密钥做加密，对方用自己传输过去的密钥解密。
国际算法：RSA
国产算法：SM2
优点：
密钥分发数目与参与者数目相同，在有大量参与者的情况下易于密钥管理。
支持数字签名和不可否认性。
无需事先与对方建立关系，交换密钥。
缺点：
速度相对较慢。
可能比同等强度的对称密码算法慢10倍到100倍。
加密后，密文变长。
密码杂凑算法 :又称为散列算法或哈希函数，一种单向函数，要由散列函数输出的结果，回推输入的资料是什么，是非常困难的。
散列函数的输出结果，被称为讯息摘要（message digest）或是 摘要（digest） ，也被称为 数字指纹 。
杂凑函数用于验证消息的完整性， 在数字签名中，非对称算法对数据签名的速度较慢，一般会先将消息进行杂凑运算，生成较短的固定长度的摘要值。然后对摘要值进行签名，会大大提高计算效率 。
国际算法:MD5、SHA1、SHA2、SHA3
国产算法:SM3
2009年国家密码管理局发布的《信息安全等级保护商用密码技术实施要求》中明确规定，一、二、三、四级信息系统应使用商用密码技术来实施等级保护的基本要求和应用要求，一到四级的密码配用策略要求采用国家密码管理部门批准使用的算法。
2010年年底，国家密码管理局公开了SM2、SM3等国产密码算法。
2011年2月28日，国家密码管理局印发的【2011】145号文中明确指出，1024位RSA算法正在面临日益严重的安全威胁，并要求各相关企业在2012年6月30日前必须使用SM2密码算法
国家密码管理局在《关于做好公钥密码算法升级工作的函》中要求2011年7月1日以后建立并使用公钥密码的信息系统，应使用SM2算法；已经建设完成的系统，应尽快进行系统升级，使用SM2算法。
2014年底，国家密码管理局启动《重要信息系统密码应用推进总体研究课题》,确定十三五密码 科技 专项。
2017年11月底，国家密码管理局下发了《政务云密码支撑方案及应用方案设计要点》。
2017年国家密码管理局发布了42项金融和重要领域国产密码应用试点任务。
2018年，中共中央办公厅、国务院办公厅印发《金融和重要领域密码应用与创新发展工作规划（2018-2022年）。
2018年，为指导当时即将启动的商用密码应用安全性评估试点工作，国家密码管理局发布了密码行业标准GM/T0054-2018《信息系统密码应用 基本要求》。
2021年3月，国家市场监管总局、国家标准化管理委员会发布公告，正式发布国家标准GB/T39786-2021《信息安全技术信息系统密码应用基本要求》，该标准于2021年10月1日起实施。
SM1 算法是分组密码算法，分组长度为 128 位，密钥长度都为 128 比特，算法安全保密强度及相关软硬件实现性能与AES相当，算法不公开，仅以IP核的形式存在于芯片中。
算法集成于加密芯片、智能 IC 卡、智能密码钥匙、加密卡、加密机等安全产品，广泛应用于电子政务、电子商务及国民经济的各个应用领域(包括政务通、警务通等重要领域)。
SM2椭圆曲线公钥密码算法是我国自主设计的公钥密码算法，是一种基于ECC算法的 非对称密钥算法， 其加密强度为256位，其安全性与目前使用的RSA1024相比具有明显的优势。
包括SM2-1椭圆曲线数字签名算法，SM2-2椭圆曲线密钥交换协议，SM2-3椭圆曲线公钥加密算法，分别用于实现 数字签名密钥协商 和 数据加密 等功能。
SM3杂凑算法是我国自主设计的密码杂凑算法，属于哈希（摘要）算法的一种，杂凑值为256位，安全性要远高于MD5算法和SHA-1算法。
适用于商用密码应用中的 数字签名 和 验证消息认证码的生成与验证 以及 随机数 的生成，可满足多种密码应用的安全需求。
SM4 分组密码算法 是我国自主设计的分组对称密码算法，SM4算法与AES算法具有相同的密钥长度分组长度128比特，因此在安全性上高于3DES算法。
用于实现数据的加密/解密运算，以保证数据和信息的机密性。软件和硬件加密卡均可实现此算法。
商用密码技术框架包括 密码资源、密码支撑、密码服务、密码应用 等四个层次，以及提供管理服务的密码管理基础设施。
密码资源层： 主要是提供基础性的密码算法资源。
密码支撑层： 主要提供密码资源调用，由安全芯片、密码模块、智能IC卡、密码卡、服务器密码机、签名验签服务器、IPSCE/SSL VPN 等商密产品组成。
密码服务层： 提供密码应用接口，分为对称和公钥密码服务以及其他三大类。
密码应用层： 调用密码服务层提供的密码应用程序接口，实现数据的加解密、数字签名验签等服务。如应用 于 安全邮件、电子印章系统、安全公文传输、移动办公平台、可信时间戳等系统。
密码管理基础设施： 独立组件，为以上四层提供运维管理、信任管理、设备管理、密钥管理等功能。
完整的PKI系统必须具有权威认证机构(CA)、数字证书库、密钥备份及恢复系统（KMC）、证书作废系统（CRL）、应用接口（API）等基本构成部分，构建PKI也将围绕着这五大系统来着手构建。
CA 系统：Ca系统整个PKI的核心，负责证书的签发。CA首先产生自身的私钥和公钥（密钥长度至少为1024位），然后生成数字证书，并且将数字证书传输给安全服务器。、CA还负责为操作员、安全服务器以及注册机构服务器生成数字证书。安全服务器的数字证书和私钥也需要传输给安全服务器。
CA服务器是整个结构中最为重要的部分，存有CA的私钥以及发行证书的脚本文件，出于安全的考虑，应将CA服务器与其他服务器隔离，任何通信采用人工干预的方式，确保认证中心的安全。
（1）甲使用乙的公钥对明文进行加密，生成密文信息。
（2）甲使用HASH算法对明文进行HASH运算，生成数字指纹。
（3）甲使用自己的私钥对数字指纹进行加密，生成数字签名。
（4）甲将密文信息和数字签名一起发送给乙。
（5）乙使用甲的公钥对数字签名进行解密，得到数字指纹。
（6）乙接收到甲的加密信息后，使用自己的私钥对密文信息进行解密，得到最初的明文。
（7）乙使用HASH算法对还原出的明文用与甲所使用的相同HASH算法进行HASH运算，生成数字指纹。然后乙将生成的数字指纹与从甲得到的数字指纹进行比较，如果一致，乙接受明文；如果不一致，乙丢弃明文。
SSL 协议建立在可靠的传输协议（如 TCP）之上，为高层协议提供数据封装，压缩，加密等基本功能。
即可以协商加密算法实现加密传输，防止数据防窃听和修改，还可以实现对端设备身份验证、在这个过程中，使用国密算法进行加密、签名证书进行身份验证、加密证书用于密钥交换
SSL协商过程：
（1）客户端发出会话请求。
（2）服务端发送X.509证书（包含服务端的公钥）。
（3）客户端用已知Ca列表认证证书。
（4）客户端生成随机对称密钥，并利用服务端的公钥进行加密。
（5）双方协商完毕对称密钥，随后用其加密会话期间的用户最终数据。
利用SSL卸载技术及负载均衡机制，在保障通讯数据安全传输的同时，减少后台应用服务器的性能消耗，并实现服务器集群的冗余高可用，大幅度提升整个业务应用系统的安全性和稳定性。此外，借助多重性能优化技术更可缩短了业务访问的响应等待时间，明显提升用户的业务体验。
基于 数字证书 实现终端身份认证，给予密码运算实现本地数据的加密存储，数字证书硬件存储和密码运算由移动终端内置的密码部件提供。
移动应用管理系统服务器采用签名证书对移动应用软件安装包进行签名，移动应用管理系统客户端对签名信息进行验签，保障移动应用软件安装包的真实性和完整性。
移动办公应用系统采用签名证书对关键访问请求进行签名验证。
采用加密证书对关键传输数据和业务操作指令，以及移动终端本地存储的重要数据进行加密保护。
移动办公系统使用商用密码，基于数字证书认证系统，构建覆盖移动终端、网络、移动政务应用的安全保障体系，实现政务移动终端安全、接入安全、传输安全和移动应用安全 。
