iOS：关于iPhone连接Xcode时，RSA加密失败的一点总结

转自:http://www.she.vc/article/18-120660-0.html

文章摘要
前言：前段时间做RSA加密的时候，在调试的过程中，经常失败，后台接收到的加密参数为空，但是这种不是经常发生，而是随机的。经过测试，发现，这种情况在单独使用真机、模拟器的时候都不发生，只有在真机连接xcode进行调试的时候才会发生。追踪：在笔者打了N多断点之后，终于找到了问题发生的根源。在RSA加密的类中，有这么一段代码：CFTypeRefpersistKey=nil;OSStatusstatus=SecItemAdd((__bridgeCFDictionaryRef)publicKey,&

前言：

前段时间做RSA加密的时候，在调试的过程中，经常失败，后台接收到的加密参数为空，但是这种不是经常发生，而是随机的。经过测试，发现，这种情况在单独使用真机、模拟器的时候都不发生，只有在真机连接xcode进行调试的时候才会发生。
追踪：

在笔者打了N多断点之后，终于找到了问题发生的根源。在RSA加密的类中，有这么一段代码：
CFTypeRef persistKey = nil; OSStatus status = SecItemAdd((__bridge CFDictionaryRef)publicKey, &persistKey); if (persistKey != nil){ CFRelease(persistKey); } if ((status != noErr) && (status != errSecDuplicateItem)) { return nil; } [publicKey removeObjectForKey:(__bridge
id)kSecValueData]; [publicKey removeObjectForKey:(__bridge id)kSecReturnPersistentRef]; [publicKey setObject:[NSNumber numberWithBool:YES] forKey:(__bridge id)kSecReturnRef]; [publicKey setObject:(__bridge id) kSecAttrKeyTypeRSA forKey:(__bridge id)kSecAttrKeyType];
// Now fetch the SecKeyRef version of the key SecKeyRef keyRef = nil; status = SecItemCopyMatching((__bridge CFDictionaryRef)publicKey, (CFTypeRef *)&keyRef); if(status != noErr){ return nil; } return keyRef;

在模拟器上测试的时候：



屏幕快照 2016-04-20 下午3.02.06.png

真机连接Xcode的时候：



屏幕快照 2016-04-20 下午3.03.43.png

问题就出在：
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)publicKey, &persistKey);

在stack overflow发现有的人也遇到了类似的问题，现总问题结如下： 1.当我在连接着Xcode的真机设备上运行app的时候,我试图获取钥匙串，却由于-34018的错误导致运行失败。缺乏钥匙串错误代码开发文档，而且也很难重现此错误(发生的概率大概30%，我也不知道为什么发生)。由于缺乏相关的文档，所以调试这种错误就变得非常困难。为什么会出现此错误，如何解决？xcode5、ios7
解决方案

方案一：你不得不通过在你的test target中添加下面的代码作为运行脚本来签名你的 .xcttest文件夹
codesign --verify --force --sign "$CODE_SIGN_IDENTITY" "$CODESIGNING_FOLDER_PATH"

方案二：在查看源码 之后，我注意到钥匙串通过一种安全进程(区别于app的进程)获取。app和安全进程通过一项称之为XPC的技术进行对话。安全进程经由XPC的启动命令启动。你可以发现真机（模拟器也是如此）app的安全进程正在运行，它的父进程也已经启动。我猜测，有可能某些未知的原因导致安全进程启动失败或者启动太慢，使得你使用它的时候还没有准备好。或许，你可以考虑如何重启安全进程。

方案三，来自苹果官方回复：

1.我们终于能够在ios8.3里重现-34018错误，这是我们查找问题根源和修复问题的第一步。

可是，我们并不能给出确切的解决时间，但是由于已经影响了很多的开发者，我们也非常希望尽快解决。

作为变通方案，我建议在在didFinishLaunchingWithOptions 和applicationDidBecomeActive: 两个方法之前添加一个小的延时给获取字符串争取一点时间。然而，好像并没有明显的作用，这就意味着除了重启app确实没有更好的解决方法。

这个问题似乎和内存压力也有一定的关系，在解决这个问题的时候，要积极处理内存警告的问题。

更新：这个复杂的问题有几种可能的原因
一些情况下是由于不正确的app签名造成的，你可以很清楚的辨别这种原因，因为它100%可以重现。 有些情况下这种问题的造成是由于iOS支持app开发环境中的一个bug造成的。由于os中的另一个bug掩盖了它的影响，排查这个问题非常困难，这就意味着这个问题在内存面临巨大压力的时候会突然出现，我们相信这个问题在ios9.3中已经解决。 我们猜测可能有其他的原因造成了这个问题

所以，如果你在运行ios9.3及以后系统的用户设备上（未和Xcode链接）遇到此问题，请记录此bug并报告给我们。）

方案四：我的app（iOS8.4）现在极少遇到 -34018的错误，在做过一些调查之后，我发现当app频繁的从钥匙串请求数据的时候就会造成这种问题。例如，在同一时间，在不同的加载模块，两次读同一个specific key 的值。为了解决这个问题，我在内存中缓存了这个值。

方案五：其他的方式对我都没有用，我清空了我设备上所有的配置文件，以及一些通配符配置文件（这些文件似乎是重点），为了这么做，去window的Devices，然后右击你的（连接）的iphone:



THffv.png

点击"Show provisioning profiles"删除相关的文件，尤其是team相关的配置文件包括带*号的文件，然后重新导入。



jyQl1.png

方案六：

我在Xcode6.2 、iphone6、ios8.3环境下，在测试设备上也出现这种问题。更清楚的说，在运行Xcode tests的时候这种情况没有发生，在我的真机，模拟器上都是正常的。

以上的方式都对我无效。

我临时的改变了获取的方式从kSecAttrAccessibleAfterFirstUnlock 到kSecAttrAccessibleAlwaysThisDeviceOnly，运行app,完美运行，且可以写到钥匙串，然后我再改回到kSecAttrAccessibleAfterFirstUnlock,问题似乎永久性的解决了。
总结：

非常遗憾，笔者这个问题仍旧没有解决，希望笔者摘录的几种解决方式给大家一点思路。