Найкраща практика зберігання та захисту приватних ключів API у додатках [закрито]

Більшість розробників додатків інтегруватимуть деякі бібліотеки сторонніх розробників у свої додатки. Якщо ви маєте доступ до такої служби, як Dropbox або YouTube, або для реєстрації аварій. Кількість бібліотек та служб сторонніх компаній приголомшує. Більшість цих бібліотек та сервісів інтегровані шляхом якихось автентифікації з сервісом, більшість випадків це відбувається за допомогою ключа API. З метою безпеки служби зазвичай генерують державні та приватні, які часто також називають секретними, ключовими. На жаль, для того, щоб підключитися до служб, цей приватний ключ повинен використовуватися для аутентифікації, а отже, ймовірно, буде частиною програми. Зайве говорити, що це стикається з величезною проблемою безпеки. Публічні та приватні ключі API можуть бути вилучені з APK за лічені хвилини та їх легко автоматизувати.

Якщо припустити, що я щось подібне до цього, як я можу захистити секретний ключ:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

Який на ваш погляд найкращий і безпечний спосіб зберігання приватного ключа? Заплутаність, шифрування, як ви думаєте?

1. Як і є, ваша компільована програма містить ключові рядки, а також постійні імена APP_KEY та APP_SECRET. Витяг ключів з такого коду самодокументації є тривіальним, наприклад, зі стандартним інструментом Android dx.

2. Ви можете застосувати ProGuard. Він залишить ключові рядки недоторканими, але він видалить постійні імена. Там, де це можливо, також будуть перейменовані класи та методи з короткими безглуздими іменами. Потім витягування ключів потребує ще деякого часу, щоб з'ясувати, який рядок служить якій цілі.

   Зауважте, що налаштування ProGuard не повинна бути такою складною, як ви боїтесь. Для початку вам потрібно лише включити ProGuard, як це зафіксовано в projekt.properties. Якщо є проблеми із сторонніми бібліотеками, можливо, вам доведеться придушити деякі попередження та / або запобігти їх затуманенню в proguard-project.txt. Наприклад:

   -dontwarn com.dropbox.**
   -keep class com.dropbox.** { *; }
   

   Це підхід грубої сили; Ви можете вдосконалити таку конфігурацію, як тільки оброблена програма працює.

3. Ви можете приховати рядки в коді вручну, наприклад, з кодуванням Base64 або, бажано, з чимось складнішим; можливо навіть рідний код. Тоді хакер повинен буде статично змінити інженерію кодування або динамічно перехопити декодування в потрібному місці.

4. Ви можете застосувати комерційний обфускатор, наприклад, спеціалізований DeGGard . Він може додатково зашифрувати / приховати рядки та класи для вас. Потім вилучення ключів потребує ще більше часу та досвіду.

5. Можливо, ви зможете запустити частини програми на власному сервері. Якщо ви можете тримати ключі там, вони знаходяться в безпеці.

Зрештою, це економічний компроміс, який ви повинні зробити: наскільки важливими є ключі, скільки часу чи програмного забезпечення ви можете собі дозволити, наскільки витончені хакери, які цікавляться ключами, скільки часу вони захочуть витрачайте, скільки коштує затримка перед тим, як зламати ключі, за якою шкалою будь-який успішний хакер поширює ключі тощо. Невеликі фрагменти інформації, як-от клавіші, важче захистити, ніж цілі програми. Внутрішньо, нічого на стороні клієнта не порушується, але ви, звичайно, можете підняти планку.

(Я розробник ProGuard і DexGuard)

Мало ідей, на мою думку, лише перша дає певну гарантію:

1. Зберігайте свої секрети на якомусь сервері в Інтернеті, а при необхідності просто захопіть їх та використовуйте. Якщо користувач збирається використовувати папку "папка", то ніщо не заважає вам робити запит на свій сайт і отримати секретний ключ.

2. Покладіть свої секрети в jni-код, додайте змінний код, щоб зробити ваші бібліотеки більшими та складнішими для декомпіляції. Ви також можете розділити рядок ключів на кілька частин і зберігати їх у різних місцях.

3. використовувати obfuscator, а також вводити в хеш-код секрет і пізніше розгортати його, коли потрібно.

4. Покладіть секретний ключ як останні пікселі одного із зображень у об’єкти. Потім, коли потрібно, прочитайте його у своєму коді. Обмежування коду повинно допомогти приховати код, який прочитає його.

Якщо ви хочете швидко ознайомитись з тим, як легко читати ви apk-код, тоді захопіть APKAnalyser:

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/

Ще один підхід - не мати секрету на пристрої в першу чергу! Див. Методи безпеки мобільного API (особливо частина 3).

Використовуючи традицію опосередкованого часу, поділіться секретом між вашою кінцевою точкою API та службою аутентифікації додатків.

Коли ваш клієнт хоче здійснити виклик API , він просить службу авторизації програми підтвердити його автентифікацію (з використанням сильних методів віддаленої атестації), і він отримує обмежений у часі (зазвичай JWT ) маркер, підписаний секретом.

Маркер надсилається з кожним викликом API, де кінцева точка може підтвердити свою підпис, перш ніж діяти на запит.

Фактична таємниця ніколи не присутня на пристрої; насправді додаток ніколи не має уявлення, чи він дійсний, чи ні, він вимагає аутентифікації та передає отриманий маркер. Як хороша користь від непрямості, якщо ви хочете коли-небудь змінити секрет, ви можете це зробити, не вимагаючи від користувачів оновлення встановлених програм.

Тож якщо ви хочете захистити свою таємницю, не мати її в додатку в першу чергу - це дуже хороший спосіб.

Старий незахищений спосіб:

Виконайте 3 прості дії для захисту API / секретного ключа ( стара відповідь )

Ми можемо використовувати Gradle для захисту ключа API або секретного ключа.

1. gradle.properties (Властивості проекту): Створення змінної з ключем.

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (Модуль: додаток): встановлення змінної в build.gradle для доступу до неї в активності або фрагменті. Додайте нижче код для buildTypes {}.

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. Доступ до нього в Активність / Фрагмент за допомогою BuildConfig програми:

BuildConfig.GoogleSecAPIKEY

Оновлення:

Наведене вище рішення корисно у проекті з відкритим кодом, щоб взяти на себе зобов'язання над Git. (Дякуємо Девіду Раусону та Ріяз-Алі за ваш коментар).

Згідно з коментарями Метью та Пабло Чегарри, зазначений вище спосіб не є безпечним, і Decompiler дозволить комусь переглядати BuildConfig за допомогою наших секретних ключів.

Рішення:

Ми можемо використовувати NDK для безпечних ключів API. Ми можемо зберігати ключі в рідному класі C / C ++ та отримувати доступ до них у наших класах Java.

Будь ласка, перейдіть на цей блог, щоб захистити ключі API за допомогою NDK

Подальші дії щодо безпечного зберігання жетонів в Android

Ключ App-Secret слід зберігати в приватному режимі, але, коли випускаєте додаток, вони можуть повернути деякі хлопці.

для тих хлопців це не буде приховувати, заблокуйте або ProGuardкод. Це рефактор, і деякі платні обскуратори вставляють кілька побітових операторів, щоб повернути jk433g34hg3 струну. Ви можете зробити 5 -15 хв довше злому, якщо працюєте 3 дні :)

Найкращий спосіб - зберегти його таким, яким він є, імхо.

Навіть якщо ви зберігаєтесь на стороні сервера (ПК), ключ можна зламати та роздрукувати. Може, це займає найдовше? У кращому випадку це питання кількох хвилин або декількох годин.

Звичайний користувач не буде декомпілювати ваш код.

Одне можливе рішення - кодувати дані у вашому додатку та використовувати декодування під час виконання (коли ви хочете використовувати ці дані). Я також рекомендую використовувати progaurd, щоб важко читати та розуміти декомпільований вихідний код програми. наприклад, я помістив кодований ключ у додаток, а потім застосував метод декодування в моєму додатку для розшифровки моїх секретних ключів під час виконання:

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

Декомпільований вихідний код захищеного додатка такий:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

Принаймні, для мене це досить складно. це те, що я роблю, коли у мене немає іншого вибору, але зберігаю значення у своїй програмі. Звичайно, ми всі знаємо, що це не найкращий спосіб, але це працює для мене.

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

Декомпільована версія:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

і ви можете знайти стільки класів шифрів за допомогою невеликого пошуку в google.

Додавши до рішення @Manohar Reddy, можна використовувати базу даних firebase або firebase RemoteConfig (з нульовим значенням за замовчуванням):

1. Зашифруйте свої ключі
2. Зберігайте його в базі даних firebase
3. Отримайте його під час запуску програми або коли потрібно
4. розшифруйте ключі та скористайтеся нею

Чим відрізняється це рішення?

• ніяких облікових даних для firebase
• доступ до firebase захищений, тому лише додатки з підписаним сертифікатом мають право робити дзвінки API
• шифрування / розшифровка для запобігання перехоплення середньої людини. Однак дзвінки вже https до firebase

Цей приклад має низку різних аспектів. Я згадаю пару моментів, які, на мою думку, не були чітко висвітлені в інших місцях.

Захист секрету в дорозі

Перше, що слід зауважити, - це те, що для доступу до API випуску скриньки за допомогою механізму аутентифікації додатків потрібно передати ваш ключ та секрет. З'єднання HTTPS, що означає, що ви не можете перехопити трафік, не знаючи сертифікату TLS. Це робиться для того, щоб людина не перехоплювала та читала пакети в дорозі від мобільного пристрою до сервера. Для звичайних користувачів це дійсно хороший спосіб забезпечення конфіденційності їх трафіку.

Те, в чому це не добре, - це перешкоджати зловмиснику завантажувати додаток та перевіряти трафік. Користуватися проксі-посередником проксі для всього трафіку на мобільний пристрій і з нього дуже просто. Для вилучення ключа програми та секрету в цьому випадку, за характером API Dropbox, не знадобиться розбирання чи зворотна інженерія коду.

Ви можете виконати фіксацію, яка перевіряє, наскільки очікується сертифікат TLS, отриманий від сервера. Це додає клієнту чек і ускладнює перехоплення трафіку. Це ускладнить перевірку трафіку в польоті, але перевірка фіксації відбувається у клієнта, тому, ймовірно, все-таки можна буде відключити тест на фіксацію. Це все ж робить важче.

Захист секрету в спокої

В якості першого кроку використання чогось типу прогуар допоможе зробити менш очевидним, де зберігаються якісь секрети. Ви також можете використовувати NDK для зберігання ключа та секрету та безпосередньо надсилання запитів, що значно зменшить кількість людей з відповідними навичками для отримання інформації. Подальша обфузація може бути досягнута, не зберігаючи значення безпосередньо в пам'яті протягом будь-якого проміжку часу, ви можете зашифрувати їх і розшифрувати їх безпосередньо перед використанням, як це запропоновано іншою відповіддю.

Більш вдосконалені варіанти

Якщо ви зараз параноїдальні щодо розміщення секрету в будь-якому місці свого додатка, і у вас є час і гроші вкласти кошти в більш комплексні рішення, то ви можете розглянути можливість зберігання облікових даних на ваших серверах (припускаючи, що у вас є). Це збільшить затримку будь-яких дзвінків до API, оскільки йому доведеться спілкуватися через ваш сервер, а також може збільшити витрати на запуск вашої послуги через збільшення пропускної здатності даних.

Тоді ви повинні вирішити, як найкраще спілкуватися зі своїми серверами, щоб гарантувати їх захист. Це важливо, щоб уникнути повторного виникнення тих самих проблем із внутрішнім API. Найкраще правило, яке я можу дати, - це не передавати жодної таємниці безпосередньо через загрозу людині в середині. Натомість ви можете підписати трафік за допомогою свого секрету та перевірити цілісність будь-яких запитів, які надходять на ваш сервер. Один із стандартних способів зробити це - обчислити HMAC повідомлення, накресленого секретом. Я працюю в компанії, яка має продукт безпеки, який також працює в цій галузі, і саме тому такі речі мене цікавлять. Насправді, ось стаття в блозі одного з моїх колег, яка стосується більшої частини цього.

Скільки я повинен зробити?

Із будь-якими порадами щодо безпеки, які вам потрібні, потрібно прийняти рішення щодо витрат / вигод щодо того, наскільки важко ви хочете, щоб хтось увірвався. Якщо ви банк, який захищає мільйони клієнтів, ваш бюджет абсолютно відрізняється від того, хто підтримує додаток у його вільний час. Заборонити комусь порушити вашу безпеку практично неможливо, але на практиці мало кому потрібні всі дзвіночки та з деякими основними запобіжними засобами можна пройти довгий шлях.

Найбільш безпечне рішення - тримати ключі на сервері та маршрутизувати всі запити, які потребують цього ключа, через ваш сервер. Таким чином, ключ ніколи не залишає ваш сервер, якщо ваш сервер захищений, то і ваш ключ. Звичайно, для цього рішення є вартість продуктивності.

Зберігайте секрет firebase databaseі отримуйте його, коли програма починається. Це набагато краще, ніж викликати веб-сервіс.

Що б ви не зробили для захисту своїх секретних ключів, це не буде справжнім рішенням. Якщо розробник може декомпілювати програму, немає можливості захистити ключ, приховування ключа - це лише захист від неясності, а також це затухання коду. Проблема із забезпеченням секретного ключа полягає в тому, що для його захисту потрібно використовувати інший ключ, і цей ключ також потрібно захистити. Придумайте ключ, прихований у коробці, що замикається ключем. Ви розміщуєте коробку всередині кімнати і зачиняєте її. Вам залишається ще один ключ, щоб убезпечити. І цей ключ все ще буде жорстко закодований у вашій програмі.

Тому, якщо користувач не введе PIN-код або фразу, немає способу приховати ключ. Але для цього вам доведеться мати схему управління PIN-кодами, що відбуваються поза діапазону, що означає через інший канал. Звичайно, це не практично для забезпечення ключів для таких служб, як API Google.

Вік старий пост, але все ще досить хороший. Я думаю, що заховати його в бібліотеці .so було б чудово, використовуючи, звичайно, NDK та C ++. .so файли можна переглядати в шестигранному редакторі, але удача, декламуючи це: P

Єдиний вірний спосіб зберегти ці приватні дані - зберегти їх на своєму сервері, і програма повинна надсилати на сервер все, що є, і сервер взаємодіє з Dropbox. Таким чином ви НІКОЛИ не поширюєте свій приватний ключ у будь-якому форматі.

Виходячи з гіркого досвіду та після консультацій з експертом IDA-Pro, найкращим рішенням є переміщення ключової частини коду в DLL / SharedObject, а потім витягнути його з сервера та завантажити під час виконання.

Чутливі дані повинні бути закодовані, оскільки зробити щось подібне дуже просто:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD