Шифрування й безпека ключів
![]() |
Це радже якакась замітка тої інформації що мені залишилась для користування, після розпитувань ШІ. Бо це фера не проста й значно довше перебирать поглиблений матеріал.
Що насправді відбувається із ключами коли їх вставляють в ті чи інші міста. Бо потреба виникла саме за потреби реалізувати можливість простого методу вивантаження зобаражень на сервер Steemitimages.com, а там особлива процедура підпису транзакцій. Кейчен такого не робить, потрібено напряму. Тож думаю яка різниця.
Якщо просто, то ключ коли передається на сайт, наприклад steemit.com якимось чином шифрується і потім використовується. За умови надійності коду, це наче безпечно, залежно від реалізації шифрування. Але є сам процес передачі ключа і його можуть свиснуть у процесі. Якщо в мене своя сторіночка лише для вивантаження зобарження та публікації допису, то чистий ключ, теж нікуди не передається по інтернету, бібліотеки все обробляють локально, а в блокчейн вже йдуть дані спеціальним чином підписані. Вся магія відбувається на пристрої по суті і це безпечно наче б то. Але є багато нюансів, бо це й ключ легко свиснуть, якщо хто захоче, бо його видно. Тож через браузер його можуть із локальноо сховища витягнуть, так легко як цукерочку у дитини поцупить.
На допомогу приходить шифрування, яке теж має свої особливості. Наприклад ідентичні методи AES-256 і ще там якась із нею в парі, яку використовує розширення для браузера Keychaine, може мати зовсім різні підходи. Але принцип десь і той самий.
Простий принцип. Чистий ключ один раз шифрується у набрі чогось іще незрозумілішого й довшого за кількістю символів. До цього додається спеціальний пароль. І вже зашифрований ключь лежить і дешифрується паролем (чи ще й пінкодом), коли треба підписати транзакцію і все, й потім знову чекаж дешифрування чи моле лежити відкритим в озу певний час сесії для нового підпису.
Так от, це може бути реалізовано різними методами. Починаючи від того, що розшифрований ключ показує в логах і озу, так і значно захищенішому методі. Бо найкращий по безпеці, це коли процес дешифрування й підпису відбувається цілком закрито й у світ виходить влеж підписані дані, без розкриття ключа навіть в озу чи ще де. Так працює кейчейн, будучи розширенням браузера, ще й має ізольоване середовище. Тому за надійності розробника, це високий рівень захисту.
Інші методи підшукувані мною, передбачають хіба складну розробку різних рішень процесів шифрування й розшифрування. Бо у самому браузері із веб сторінки далеко не розженешся й не буде тої безпеки зберігання ключа у локальному сховищі. Бо простий метод показав, що там просто лежить зашифрований ключ і все його видно. На steemit.com, якийсь різновид шифрування, чи то підпису чи ще чого, щоб автоматично писати дописи й коментарі. Проте там є сервена частина й припускаю, є середовище захищеніше. І не ясно чи кешують ці ключі в чистому вигляді чи ні, бо десь згадувалось.
Щось для нативного застосунку значно простіше зробити типу Keystore, де буде ключик шифрований всередині захований і підпсуватись, але треба правильно підібрати й організувати процес шифруванни й підпису у закритому процесі. Тоді це буде нормально. Але то по суті, лише для вивантаження зображень, через окремий редкатор, що все було зручно й в одній коробці. То для цього можна окремий акаунт заветси для вивантаження, а публікувати через кейчейн, якщо є інтернет, то по суті можна на сторінку заходити із мобільного навіть. Інша справа застосунок, є навіть розробки мобільного кейчейну і щось таке, але він не підтримує підпис вивантаження зображень. Точніше про це каже ШІ і шось не виходить підписати таку транзакцію. Тож або постає питання в безпечній авторизації та загалом для себе б знати як краще поводитись із ключами й виконанням підпису.
І постає питання, якщо для себе, й мобільного чи десктопного застосунку, де кейчен просто нікуди прикрутить, то хіба розбираться із процедурами шифрування, щоб забезпечити надійніть. Або просто чистий аканут, щоб ключ був і можна й відкрито його тримати. А для публікації використовувати SteemLogin, або SteemAuth (хто зна чи працює, бо не перевірено).
А щодо безпеки ключа, із того що було перевірено, щоб авторизуватись, поки що кейченй чи подібний застосунок, який зроблено надійно із дотримання правильності протоколу й закритості, буде надійніше. Бо та ж авторизація через стімлогін, вимагає процедури підпису активним ключем, тобто фінансови, і так чи інакше його десь бува раз треба вводить. Тож не багато варівантів.
Тож можна й окремий аканут завести й просто радіть.
Або використовуати кейчейн і вантажити теж лівим ключем. Або таки зробить хороший сховок і метд для шифрування... Бо ті ліві сервіси бува теж просять ввеедення ключа фінасового..
