2017-02-22 12 views
1

Я работаю над приложением ios, которое содержит некоторые файлы, которые шифруются AES-128, поэтому для дешифрования этих файлов я использую некоторые сторонние библиотеки, такие как cryptoswift, прямо сейчас быстрый код только я пишу свою собственную логику для дешифрования данных с помощью ключей, но я хочу надежно хранить эти ключи, для андроида я написал свою логику в родной библиотеке, вот что лучший способ защитить мой секретный ключКак хранить существующую строку тайно в приложении ios swift

+0

Лучше всего избегать использования CryptoSwift, а другие - от 100 до 1000 раз медленнее, чем на основе Common Crypto. Common Crypto от Apple является сертифицированным FIPS и, как таковой, был хорошо проверен, использование CryptoSwift дает шанс на правильность и безопасность. – zaph

+0

Вы можете обфускать хранилище ключей в своем коде; храните его в нескольких кусках, храните его в форме, требующей некоторых математических операций для восстановления ключа и т. д., это затруднит для злоумышленника извлечение вашего ключа, но мало что можно сделать для защиты от определенного злоумышленника, поскольку в конечном счете ключ находится где-то. – Paulw11

+0

@ Paulw11 Защита от владельца по существу невозможна, но защита от кого-то с физическим хранением зависит от качества кода блокировки, заблокированное устройство защищено от практически любого злоумышленника. – zaph

ответ

4

Вы должны использовать iOS Keychain Services, чтобы хранить ключи в безопасности.

В Swift имеется несколько библиотек, которые обеспечивают легкий доступ к цепочке ключей. См. Здесь: https://github.com/vsouza/awesome-ios#keychain

+0

Как добавить свой ключ в брелок, если я напишу эту логику в быстром, кто-нибудь может увидеть эту клавишу – skyshine

+0

Это зависит от архитектуры механизма генерации ключа ... Если вы создаете ключ на устройстве, например, вам никогда не придется писать ключ в быстрый код. Если у вас есть предварительно сгенерированные ключи, вы должны предоставить им приложение и попросить пользователя ввести пароль, например. – aofs

+0

@parker Определить «кто угодно»? Владелец устройства может, так как у них есть владение и полный контроль. То же самое относится к устройствам без кода блокировки. Для защиты от пользователя требуется DRM, а не только шифрование. – zaph

0

Для хранения конфиденциальной информации вы всегда должны использовать брелок. Вы можете использовать следующий пример кода, отправленный яблоком, чтобы узнать подробно Generic Keychain .Хорошее кодирование !!!

-1

EDIT: См. Обсуждение под ним. Мудрый вывод: возможно, лучший ответ: «Не беспокойтесь, поместите ключ в код», есть большой рабочий фактор для получения ключа.

Если вы храните секретный токен в приложении, существует риск, что он будет легко восстановлен как простая строка. Вы можете узнать больше об этом в Reverse Engineering iOS Apps.

Вы не можете предотвратить его полностью, но вы можете скрыть данные о пароле путем разделения на более мелкие куски пароля, держать их друг от друга в коде, и использовать некоторый алгоритм немого дешифрования для получения окончательной формы, как это:

func crypt(string: String) -> [UInt32] { 
    return string.unicodeScalars.enumerated().map { index, char in 
     return char.value + UInt32(index) 
    } 
} 

func decrypt(chars: [UInt32]) -> String { 
    return chars.enumerated().map { (index, char) -> String in 
     let s = UnicodeScalar(char - UInt32(index))! 
     return "\(Character(s))" 
    }.joined() 
} 

let clearPassword = "Acb,321" 
let cryptedChars = crypt(string: clearPassword) 
let decrypted = decrypt(chars: cryptedChars) 

let c1: UInt32 = 65 
let c2: UInt32 = 100 
let c3: UInt32 = 100 
let c4: UInt32 = 47 
let c5: UInt32 = 55 
let c6: UInt32 = 55 
let c7: UInt32 = 55 

let decryptedScattered = decrypt(chars: [c1, c2, c3, c4, c5, c6, c7]) 

Не идеально, но должно быть достаточно для простых атак, и более продвинутые, возможно, слишком дороги для продолжения.

+0

Вы делали все возможное, пока «не использовали какой-то алгоритм глухого дешифрования». – zaph

+0

@zaph И не могли бы вы подробнее рассказать, почему так? В каком другом виде вы предлагаете хранить токен внутри двоичного кода? Брелок доступен только во время выполнения, а не во время компиляции. Случайный ключ, который вы предложили выше, не решает проблему вообще, когда у вас уже зашифрованы файлы с данным секретом. –

+0

Зачем использовать «некоторый алгоритм дешифрования», когда AES доступен? Слово «немой» говорит все. – zaph