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

前言:


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

追踪:


在笔者打了N多断点之后,终于找到了问题发生的根源。在RSA加密的类中,有这么一段代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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

问题就出在:

1
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)publicKey, &persistKey);

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

解决方案


方案一:
你不得不通过在你的test target中添加下面的代码作为运行脚本来签名你的 .xcttest文件夹

1
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,问题似乎永久性的解决了。

总结:


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