一、主流保证数据安全的方式

1、网络传输安全

1.采用HTTPS通信协议
可防止抓包窃取、篡改传输数据,大大增加了中间人攻击的成本。

2.对敏感数据进行签名校正
采用非对称加密的方式,对敏感数据使用密钥加密,到了客户端用公钥解密,验证数据一致性,防止通信过程中被篡改。

3.采用密文传输
别人即使截取了传输信息,也无法看懂其中的意思。

2、本地存储数据安全

1.数据库加密
通过越狱设备可以很容易地把整个应用包(包括里面的数据)copy出来,这样就可以获取里面的数据库,对于没有加密的数据库就可以非常轻易地读取里面的信息,造成信息的泄漏。 数据库加密可分两个维度:1.整个数据库加密;2.对部分字段先加密再存数据库。 对部分字段加密并不适合多字段的加密存储,容易导致加密数据太过分散,影响性能。所以推荐对整个数据库加密。

2.KeyChain存储敏感数据
KeyChain是iOS系统级的存储方式,安全性无需质疑,且删除应用或者升级系统依然可以保留里面的信息。

3、源码安全

使用越狱设备可以很轻易地把应用砸壳,从而把源码dump下来,即使是没有太多经验的开发者也可以得到应用的类信息,包括函数名等。使用IDA等反编译工具可以看到应用的一些类名和方法名,进而可以分析功能实现的逻辑。

1.字符串混淆
对应用程序中使用到的字符串进行加密,保证源码被逆向后也能保护明文字符串。

2.类名、方法名混淆
市面上很多iOS应用都没有混淆类名方法名,以致于很容易使用class-dump下来,从而进行hook操作,一步一步实现iOS微信自动抢红包(非越狱)是很有趣的一个应用。这个库可以混淆OC的类名、协议、属性还有方法名。

3.程序结构混淆加密
对应用程序逻辑结构进行打乱混排,保证源码可读性降到最低。可参考这个库

4.反调试、反注入等一些主动保护策略
加入第三方安全性SDK

二、对数据库加密的研究

1、主流数据库加密方式

The SQLite Encryption Extension(收费)

SQLiteEncrypt(收费)

SQLiteCrypt(收费)

SQLCipher(开源免费)

只有SQLCipher是免费的,所以本文主要对SQLCipher进行研究。

2、引入SQLCipher第三方库

1.手动引入
请参考官方教程

2.使用CocoaPods
pod 'FMDB/SQLCipher', '2.5'

3、SQLCipher的可行性研究

1.新建加密数据库

若没有旧数据的情况下使用很简单,只需要在FMDatabase里面的-open-openWithFlags:方法里面添加[self setKey:kDatabaseEncryptKey];即可。 如下图所示

添加密钥

但是在团队协作中,如果直接修改pod仓库里面的文件,可能不好同步,下面有一个技巧,就是继承FMDatabase和FMDatabaseQueue并重载其中的方法。

继承FMDatabase的子类需要重载以下方法

- (BOOL)open {
    if (_db) {
        return YES;
    }
    int err = sqlite3_open([self sqlitePath], &_db );
    if(err != SQLITE_OK) {
        NSLog(@"error opening!: %d", err);
        return NO;
    } else {
        // 设置密钥
        [self setKey:kDatabaseEncryptKey];
    }
    if (_maxBusyRetryTimeInterval > 0.0) {
        // set the handler
        [self setMaxBusyRetryTimeInterval:_maxBusyRetryTimeInterval];
    }
    return YES;
}

- (BOOL)openWithFlags:(int)flags {
    if (_db) {
        return YES;
    }
    int err = sqlite3_open_v2([self sqlitePath], &_db, flags, NULL /* Name of VFS module to use */);
    if(err != SQLITE_OK) {
        NSLog(@"error opening!: %d", err);
        return NO;
    } else {
        // 设置密钥
        [self setKey:kDatabaseEncryptKey];
    }
    if (_maxBusyRetryTimeInterval > 0.0) {
        // set the handler
        [self setMaxBusyRetryTimeInterval:_maxBusyRetryTimeInterval];
    }
    return YES;
}

- (const char*)sqlitePath {
    if (!_databasePath) {
        return ":memory:";
    }
    if ([_databasePath length] == 0) {
        return ""; // this creates a temporary database (it's an sqlite thing).
    }
    return [_databasePath fileSystemRepresentation];
}

继承FMDatabaseQueue的子类只需要重载一个方法

+ (Class)databaseClass {
    return [FMEncryptDatabase class];
}

使用的时候只需要更改下面的语句

// 原:
self.normalQueue = [FMDatabaseQueue databaseQueueWithPath:self.normalDbPath];
// 改为:
self.encryptQueue = [FMEncryptDatabaseQueue databaseQueueWithPath:self.encryptDbPath];

2.加密已有数据库

加密已有数据库我已经封装成下面的方法:

/**
 加密数据库(保留原有数据库)
 */
+ (BOOL)encryptDatabase:(NSString *)origPath toPath:(NSString *)toPath {
    sqlite3 *db;
    if (sqlite3_open([origPath UTF8String], &db) == SQLITE_OK) {
        char *err = NULL;
        sqlite3_exec(db, [[NSString stringWithFormat:@"ATTACH DATABASE '%@' AS encrypted KEY '%@';", toPath, kDatabaseEncryptKey] UTF8String], NULL, NULL, &err);
        sqlite3_exec(db, "SELECT sqlcipher_export('encrypted');", NULL, NULL, &err);
        sqlite3_exec(db, "DETACH DATABASE encrypted;", NULL, NULL, &err);
        sqlite3_close(db);
        return err ? NO : YES;
    } else {
        sqlite3_close(db);
        NSLog(@"Open db failed:%s", sqlite3_errmsg(db));
        return NO;
    }
}

这里有两点需要注意的地方:
1、这里必须使用全路径
2、加密后的queue必须同步更换为FMEncryptDatabaseQueue,不然无法读写数据

3.解密已加密数据库

解密已加密的数据库已封装为以下方法:

/**
 解密数据库(保留原有数据库)
 */
+ (BOOL)unencryptDatabase:(NSString *)origPath toPath:(NSString *)toPath {
    sqlite3 *db;
    if (sqlite3_open([origPath UTF8String], &db) == SQLITE_OK) {
        char *err = NULL;
        sqlite3_exec(db, [[NSString stringWithFormat:@"PRAGMA key = '%@';", kDatabaseEncryptKey] UTF8String], NULL, NULL, &err);
        sqlite3_exec(db, [[NSString stringWithFormat:@"ATTACH DATABASE '%@' AS plaintext KEY '';", toPath] UTF8String], NULL, NULL, NULL);
        sqlite3_exec(db, "SELECT sqlcipher_export('plaintext');", NULL, NULL, &err);
        sqlite3_exec(db, "DETACH DATABASE plaintext;", NULL, NULL, &err);
        sqlite3_close(db);
        
        return err ? NO : YES;
    } else {
        sqlite3_close(db);
        NSLog(@"Open db failed:%s", sqlite3_errmsg(db));
        return NO;
    }
}

这里也有两点需要注意的地方:
1、这里必须使用全路径
2、解密后的queue必须同步更换为FMDatabaseQueue,不然无法读写数据

4、SQLCipher性能分析

本次性能分析主要从两个维度下手: 1.对比无加密数据库和加密数据库的插入数据速度; 2.加密已有数据的数据库耗时。

本次测试都基于iOS10.3的iPad mini2下进行。

1.对比插入数据速度

规则:对比无加密数据库和加密数据库使用事务时,在插入1w条、5w条和10w条8个字段的数据的耗时,每组数据测试5次,最后取平均值。最后的测试结果如下图所示:

插入测试结果

结论:两者相差在4%左右,在移动设备上存储大数据的情况很少,所以我认为是完全可以接受的。

2.测试加密数据库耗时

规则:对比存储1w条、5w条和10w条数据的数据库加密的耗时,每组数据测试5次,最后取平均值。最后的测试结果如下图所示:

加密耗时测试结果

结论:加密过程需要一定的时间,且跟数据库所存储的数据量有关,数据量越大耗时越长,从本次的测试结果来看,加密存储10w条数据的数据库耗时1.38s是可以接受的。

5、采用SQLCipher存在的风险

1、SQLCipher依赖本地存储的字符串进行数据库的加密和解密,如果这个字符串被泄漏出去,本地的数据库依然容易被解密,进而被读取里面的信息。可采用KeyChain保存? 2、加密已存储大数据的数据库会消耗一定的时间,这段时间怎么处理才能让用户无感知?加密失败了怎么处理? 3、欢迎大家补充。。。

6、本文demo