UR3LCM/qrp(p)

Міркування щодо GPG-QSL

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

QSL-обмін є важливою частиною HAM-radio. Він виконує важливу функцію, засвідчуючи саму подію радіо-обміну. Без QSL-картки факт радіосполучення залишається просто чуткою. В паперових QSL-картках відчувається подих далеких мандрів. Вони несуть у собі романтику, стають предметом колекціонування. Проте, сьогодення накладає свої відбитки. Робота QSL-бюро нерідко стає предметом жорстких суперечок. Робота сучасних поштових служб також викликає невдоволення. Проблему вирішують сучасні IT-технології. Internet дозволяє за лічені секунди сповістити кореспондента.

Переглядаючи Internet, я зустрів якось на одному із ham-форумів бесіду
про програми, якими зручніше створити заповнену QSL-card у jpeg форматі, щоб потім надіслати її email-ом кореспондентові.
Стверджують, що серед японських радіоаматорів це є дость поширено. Форум наштовхнув мене на роздуми про електронні qsl.
Дивно, що ось уже і Інтернет став загальнодоступним, і цифрова комерція розвинулася. Банківські програми стоять у кожного підприємця. Багато хто користується електронними магазинами, вносить плату електронними грошима, надсилає електронні звіти. Діє закон про цифрові підписи. Проте ці IT-технології обходять ham-radio стороною. Здається, - що заважає підтвердити qso засвідченним електронним підписом листом?
Щоб побачити, як це виглядає, досить уважніше глянути наприклад на квитанцію про сплату за комунальні послуги.
Але замість того, щоби впровадити цифрові підписи, - організовують eQSL, LoTW etc із велетенськими базами даних і відповідними витратами на обслуговування. Міркувань про децентралізацію якось не чути.
Хоча для електронних підписів досить підтримувати свою радіаматорську мережу серверів ключів. Або скористатися загальними публічними центрами. А далі засвідчуй хоч ASCII "CFM two-way CW QSO with ..", хоч jpeg, хоч pdf. Можна і формат для ASCII QSL встановити.
IMHO видатки на обслуговування всесвітньої бази даних qso, і на осбслуговуння серверів ключів, просто не порівняти.

Тут я описую власні міркуваня щодо застосування цифрових підписів для QSL-обміну.
Цілком припускаю, що викладене мною може бути вже давно описане радіоаматорами, нині вже застосовується для HAM-radio, і я тут "винаходжу велосипед". Тоді.. Вибачайте за необізнаність!


РОЗГЛЯНЕМО, ЯК МОЖЕ ВИГЛЯДАТИ QSL ОБМІН ІЗ ЦИФРОВИМИ ПІДПИСАМИ:

1. Радіоаматори встановлюють на свої комп'ютери підтримку GPG, наприклад пакет GnuPG, і створюють електронні ключі для підпису та перевірки QSL.

2. Кожен радіоаматор публікує свій відкритий ключ на інформаційному сервері, який може являти собою, як спеціалізований сервер ключів, так і просто радіоаматорський Web-портал.

3. Інформаційний сервер зберігає опублікований ключ та час від якого цей ключ почав діяти. У разі web-сервера, ця дата вказується поряд із відкритим ключем у заздалегідь узгодженому форматі.

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

5. На інформаційному сервері зберігається історія встановлення ключів із датами їх дії.

6. Радіаматори безпосередньо обмінюються між собою завіреними цифровими підписами відкритими (не шифрованими) QSL-повідомленнями.

7. Кожне QSL-повідомлення містить позначку ключа, яким повідомлення було підписано. Це може бута дата оформлення, або т.зв. відбиток ключа (fingerprint).

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

Одже, все виглядає досить просто. На інформаційному сервері зберігаються лише відкриті ключі. Радіаматори обмінюються між собою QSL-повідомленнями безпосередньо. QSL-обмін функціонує розосереджено.


РОЗГЛЯНЕМО ПРИКЛАДИ РЕАЛЬНОЇ РОБОТИ ЦІЄЇ СИСТЕМІ НА ОСНОВІ ПАКЕТУ GNUPG
ДЛЯ ОС GNU LINUX:


ЯК СТВОРИТИ КЛЮЧІ ДЛЯ ПІДПИСУ:

0. Вважаємо, що Ви працюєте із ОС GNU Linux і пакет GnuPG уже встановлений.

1. Переглянемо раніше створені ключі:
$ gpg --list-keys
Жодного ключа ще немає.

2. Створимо ключ для підписів QSL
$ gpg --gen-key
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 3
DSA keys may be between 1024 and 3072 bits long.
What keysize do you want? (2048) 1024
Requested keysize is 1024 bits
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) "

Real name: ur3lcm-201001010000
Email address: ur3lcm@ukr.net
Comment: gpg-qsl
You selected this USER-ID:
"ur3lcm-201001010000 (gpg-qsl) "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
Тут треба двічі ввести пароль.
Цей пароль у подальшому буде ще потрібний, тож його треба добре запам'ятати.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++.++++++++++++++++++++++++++++++.+++++..++++++++++..+++++++++++++++.++++++
Тут посилено вовтузимо мишою, і в такий спосіб генеруємо системні переривання, які мають пожвавити роботу генератора випадкових чисел, що застосовується для створення ключів.
++++++++++++++++++++++++++++++++++.+++++++++++++++.++++++++++>++++++++++......
..........................+++++

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 276 more bytes)
gpg: key 0C8C39EF marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024D/0C8C39EF 2011-01-30
Key fingerprint = 45D3 07CE 0C52 39D5 431F 4034 6343 AEDA 0C8C 39EF
uid ur3lcm-201001010000 (gpg-qsl)

Note that this key cannot be used for encryption. You may want to use
the command "--edit-key" to generate a subkey for this purpose.
3. Переглянемо створені ключі:
$ gpg --list-keys

/root/.gnupg/pubring.gpg
------------------------
pub 1024D/0C8C39EF 2011-01-30
uid ur3lcm-201001010000 (gpg-qsl)
Створено DSA ключі із довжиною 1024 байти з ідентифікатором '0C8C39EF'
Створені ключі зберігаються ось тут:
$ ls ~/.gnupg/
gpg.conf pubring.gpg random_seed secring.gpg trustdb.gpg

Один ключ - закритий(таємний), другий - відкритий(публічний)

Закритий ключ дозволяє підписувати дані, і його треба надійно оберігати.
Треба також пам'ятати введений пароль.

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


ЯК ОПУБЛІКУВАТИ ВІДКРИТИЙ КЛЮЧ:

1. Роздрукуємо відкритий ключ із ідентифікатором 0C8C39EF у текстовому вигляді
$ gpg --armor --export 0C8C39EF 
можна і так:
$ gpg --armor --export ur3lcm-201001010000

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)

mQGiBE1Fb/URBACjws7GnyjNDSnJZK/rEBjGHNG/yQo0knpR86p8Il2v3odD9T/x
AMGUrmSKZYjQOVAW/Fy8ZfjHe2D+pE0d7nt1jNfD++JIXSQuZE/SeHW1i5I1MPPn
f82AxbojER3aGQM7wYa3GO7zcYrhzeZ0k9x9MtaoDNq+JXyw+pLyB41oHwCgiqKD
A7sSDJO0PpBA2E6xpL2R9s0EAJGDbDTSXOVSI3NvAFEYvlCTXJy1n4N4vv/QmUm0
o12LLNp3p4dEHDhJS7Ua6ZT1zKbOSfT7qFnMixNIL8/ma0qnwz8PkY1OuBf441Cn
DK1X6T+FM1jAKduWgci1srYC9DhJR43w5lmbtcta718ccoFYfnQwyAGsxFj0lZFS
96yQA/41AnqfCk6DUI1WsedzFHdUM3NwlZZ6OsOdJrb0blthID59gJkR0A2eOYgh
oyempPcoEwCE2NPO0EJUkPj0Jp8ZGRCtvqoUJxWaMfP/eOGMwBcgCvbphepbHGrS
FBcFikygy/HFDdXqdd3B9ghHe7vcNYp4T2HTogV4RaSCPmY8SLQhdXIzbGNtIChn
cGctcXNsKSA8dXIzbGNtQHVrci5uZXQ+iGIEExECACIFAk1Fb/UCGwMGCwkIBwMC
BhUIAgkKCwQWAgMBAh4BAheAAAoJEGNDrtoMjDnvcHgAni3RpIVnfyP5LHmuhh0w
E958o6xpAJ4x9eDqnswNV/ovwDBuy+jdDryeZQ==
=wTfy
-----END PGP PUBLIC KEY BLOCK-----
Цей текст можна відкрито опублікувати. Він дозволяє лише перевірити цілісність підписаних даних, але не дозволяє ані підписувати дані, ані відновити закритий ключ.

2. Публікуємо ключ у будь-який зручний спосіб.


ЯК ПІДПИСАТИ QSL ЦИФРОВИМ ПІДПИСОМ:

1. Створимо тестову(умовну) ASCII QSL:
$ { echo "UR3LCM; CFM CW QSO with EM0TEST; $(LANG=C date -u +%b-%d-%y\ %H:%M) UTC; MODE:2xCW; RST 559; QTH:Kharkiv; Loc:KO80ca; OUTPUT:4W; OPR:Ihor; NOTES:PSE GPG-QSL, 73"; echo '45D3 07CE 0C52 39D5 431F  4034 6343 AEDA 0C8C 39EF' } >em0test-$(date -u +%y%m%d%H%M)-qsl

$ ls *-qsl
em0test-1101301424-qsl
$ cat em0test-1101301424-qsl
UR3LCM; CFM QSO with EM0TEST Jan-30-11 14:24 UTC; MODE:2xCW; RST 559; QTH:Kharkiv; Loc:KO80ca; OUTPUT:4W; OPR:Ihor; NOTES:PSE GPG-QSL, 73
45D3 07CE 0C52 39D5 431F 4034 6343 AEDA 0C8C 39EF
2. Підпишемо створену ASCII-QSL:
$ gpg --clearsign em0test-1101301424-qsl

You need a passphrase to unlock the secret key for
user: "ur3lcm (gpg-qsl) "
Набираємо введений під час створення ключів пароль(гадаю, що Ви його пам'ятаєте)
1024-bit DSA key, ID 0C8C39EF, created 2011-01-30
3. Переглянемо результат:
$ ls e*
em0test-1101301424-qsl em0test-1101301424-qsl.asc

Підписана ANSII-QSL у файлі із розширенням .asc

4. Переглянемо підписану ASCII-QSL:
$ cat em0test-1101301424-qsl.asc -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
UR3LCM; CFM QSO with EM0TEST Jan-30-11 14:24 UTC; MODE:2xCW; RST 559;
QTH:Kharkiv; Loc:KO80ca; OUTPUT:4W; OPR:Ihor; NOTES:PSE GPG-QSL, 73
45D3 07CE 0C52 39D5 431F 4034 6343 AEDA 0C8C 39EF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk1FidoACgkQY0Ou2gyMOe8EzACePH0Tlsp3HCM5dgP6cHhZoAy6
GbwAnjMuVuPm7Wgb5hzICRUHFxcIB/AU
=C8Tp
-----END PGP SIGNATURE-----

ЯК ПЕРЕВІРИТИ ПІДПИСАНУ QSL:

1. За датою оформлення QSL, або за відбитком ключа у QSL, визначимо
ключ для перевірки.

2. Якщо ключ застосовується вперше, - зчитаємо його:
$ wget -c http://ur3lcm.ho.ua/ur3lcm-201001010000.asc

3. Імпортуємо ключ у нашу систему:
$ gpg --import ur3lcm-201001010000.asc

4. Переглянемо ключі:
$ gpg --list-keys

5. Додатково пресвідчимося, що імпортовано саме потрібний ключ:
$ gpg --fingerprint ur3lcm-201001010000

Порівняємо отриманий відбиток ключа із опублікованим на сайті.

6. Підпишемо імпортований ключ для подальшого локального користування:
$ gpg --lsign-key ur3lcm-201001010000

Пункти 1..5 необхідно виконати для кожного ключа кожного кореспондента лише раз.

7. Перевіримо підписану QSL:
$ gpg --verify em0test-201101301424-qsl.txt
gpg: Signature made Sun Jan 30 16:32:15 2011 EET using DSA key ID 0C8C39EF
gpg: Good signature from "ur3lcm-201001010000 (gpg-qsl) "
Перевірено!
8. Перевіряємо інші підписані QSL від цього кореспондента

Спробуємо підробити підписану QSL:
1. Створимо копію підписаної QSL і трохи відредагуємо її:
$ cp  em0test-1101301424-qsl.txt em0test-1101301424-edited-qsl.txt
$ vi em0test-1101301424-edited-qsl.txt
$ cat em0test-1101301424-edited-qsl.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

UR3LCM; CFM QSO with AA1AAA Jan-30-11 14:24 UTC; MODE:2xCW; RST 559; QTH:Kharkiv; Loc:KO80ca; OUTPUT:4W; OPR:Ihor; NOTES:PSE GPG-QSL, 73
45D3 07CE 0C52 39D5 431F 4034 6343 AEDA 0C8C 39EF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1FidoACgkQY0Ou2gyMOe8EzACePH0Tlsp3HCM5dgP6cHhZoAy6
GbwAnjMuVuPm7Wgb5hzICRUHFxcIB/AU
=C8Tp
-----END PGP SIGNATURE-----
2. Перевіримо відредаговану копію:
$ gpg --verify em0test-1101301424-edited-qsl.txt
gpg: Signature made Sun Jan 30 16:32:15 2011 EET using DSA key ID 0C8C39EF
gpg: BAD signature from "ur3lcm (gpg-qsl) "
Перевірка показала, що повідомлення було змінено.
Підробка не вдалася!
Як бачите, все працює!

Тепер треба ще визначити формат ASCII QSL-повідомлення та формат файлів.
Наприклад, вказувати в іменах файлів кличний знак (callsign) станції і дату:
ur3lcm-201001010000.asc - відкритий ключ, який діє від 00:00 UTC, 01 січня 2010 року;
ur3lcm-201101301200.qsl - qsl із підписом від ur3lcm
Дату оформлення qsl, або відбиток ключа, можна було би додавати і у текст QSL

Залишається "загорнути" все описане у зручний front-end, і система GPG-QSL стане остаточно готовою до роботи.

©Ihor Sokorchuk (UR3LCM), 2010-2013

ПОВЕРНИСЬ