от Пейо Попов(23-02-2004)

рейтинг (32)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване

Съдържание

За този документ

Този документ е превод на първа глава от The GNU Privacy Handbook. Преводът е част от проекта за защита на неприкосновеността на личната информация и има за цел да създаде достъпно и разбираемо за всеки ръководство за използване на GnuPG.

За GnuPG

GnuPG е средство за осигуряване сигурност в комуникациите. Тази глава се опитва да даде бърза представа за основните възможности на GnuPG. Това включва създаването на двойка ключове, обмена и подписването на ключовете, шифрирането и дешифрирането на документи, и удостоверяване на автентичността на документи, чрез цифровото им подписване. Тук няма да навлизаме в подробности за същността на криптографията с публичен ключ, криптирането и електронното подписване. Тези въпроси са засегнати в Глава 2. Няма също да се спираме на това как е най-добре да се ползва GnuPG. Това е предмет на Глава 3 и 4.

GnuPG използва криптография с публичен ключ, която позволява на потребителите да осъществяват сигурна комуникация. В криптографията с публичен ключ, всеки потребител притежава двойка ключове, състояща се от частен и публичен ключ. Частният ключ се пази в тайна и никога не трябва да бъде разкриван. Публичният ключ може да бъде даван на всеки, с който потребителя желае да комуникира. GnuPG изпозва малко по-усложнена схема, при която потребителя има основна (първична) двойка ключове и нула или повече допълнителни и подчинени на първата двойки ключове. Първичната и допълнителните двойки ключове са обединени, за да улесняват управлението на ключовете и те могат да се приемат за една двойка ключове.

Създаване на нова двойка ключове

Опцията --gen-key се използва за създаването на нова първична двойка ключове. 

Please select what kind of key you want:
 (1) DSA and ElGamal (default)
 (2) DSA (sign only)
 (5) RSA (sign only)
 Your selection?

GnuPG има възможност да създаде няколко различни типа двойки ключове, но преди всичко първичния ключ трябва да има възможност да подписва. Поради тази причина съществуват само три възможности. Първата практически създава две двойки ключове. Двойката ключове използващи DSA алгоритъма е основна двойка, с която може единствено да се подписва. Вторичната двойката ключове използващи ElGamal алгоритъма се създава, за да се шифрира информация. Втората възможност е сходна на първата, но при нея се създава само DSA двойка. Възможността под номер пет служи за създаване на двойка ключове по алгоритъма RSA, с чиято помощ може само да подписваме цифрово. За повечето потребители подразбиращата се опция (1) е това, което им е нужно.

Размерът на DSA ключа трябва да бъде между 512 и 1024 бита, а размера на ElGamal ключовете може да бъде произволен. GnuPG, обаче, изисква ключовете да не бъдат по-малки от 768 бита. Затова, ако изберем първата възможност DSA ключа ще бъде 1024 бита дълъг и ще бъде представена възможност за избор на дължината на ElGamal ключа. 
About to generate a new ELG-E keypair.
 minimum keysize is  768 bits
 default keysize is 1024 bits
 highest suggested keysize is 2048 bits
 What keysize do you want? (1024)
Колкото е по-дълъг ключа, толкова е по-малко уязвим на атаки с груба сила, но почти за всички цели подразбиращата се дължина на ключа е подходяща, тъй като ще е по-разумно да се заобиколи криптиранено, отколкото да се направи опит да се дешифрира чрез груба сила. Освен това, колкото е по-голяма дължината на ключа, толкова по-бавно ще се извършват операциите по шифриране и дешифриране. Веднъж избрана, дължината на ключа не може да бъде променяна.

Най-накрая, трябва да бъде избрана датата на която ще изтече валидността на ключа. Ако сте избрали първата възможност и DSA и ElGamal ключовете ще изтекат на една и съща дата. 

Please specify how long the key should be valid.
 0 = key does not expire
 <n>  = key expires in n days
 <n>w = key expires in n weeks
 <n>m = key expires in n months
 <n>y = key expires in n years
 Key is valid for? (0)

За повечето потребители е подходящ ключ, който няма срок на валидност. Датата на изтичане на валидност на ключа, трябва да бъде грижливо избрана, защото въпреки че тя може да бъде променена в последствие, ще е трудно да уведомим за това всички, които го притежават.

За да бъде свързана двойката ключове с вас трябва да въвете потребителски идентификатор. 

You need a User-ID to identify your key; the software constructs the user id
 from Real Name, Comment and Email Address in this form:
 "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
 
 Real name:

Само един потребителски идентификатор се създава при създаването на двойката ключове, но е възможно в последствие да се създават и допълнителни идентификатори, ако желаете да ползвате ключа в една или повече социални роли. Примерно като служител на дадена фирма и политически активист от друга страна. Потребителския идентификатор трябва точно да бъде избран внимателно, защото след като е създаден веднъж, той не може да бъде променян.

Следващата стъпка е да изберем парола, с която GnuPG ще защити създадените двойки ключове. 

You need a Passphrase to protect your private key.    
 
 Enter passphrase:

Няма ограничения за дължината на паролата и тя трябва да бъде внимателно избрана. От гледна точка на сигурността, паролата за криптиране на частните ключове е една от най-уязвимите точки в GnuPG (и другите системи базирани на асиметрично криптиране), защото тя е единствената преграда между вашия частен ключ и вероятния злонамерен човек, целящ да се добере до частния ви ключ. В най-добрия вариант паролата не трябва да използва думи, които се срещат в речник и трябва да съчетава възможно най-много типове символи. Изборът на добра парола е критичен за сигурността на GnuPG.

Създаване на отменящ сертификат

След като създадете вашата двойка ключове, вие незабавно трябва да създадете и отменящ сертификат за първичния публичен ключ чрез опцията: --gen-revoke. Ако забравите вашата парола или вашия частен ключ е загубен или компроментиран отменящият сертификат служи, за да бъдат уведомени останалите, че този публичен ключ не трябва да се използва повече. Отмененият публичен ключ все още може да се използва за проверка на подписи направени в миналото, но не може да се използва, за да се криптират бъдещи съобщения към вас. Отмяната на публичния ключ не влияе на възможността ви да дешифрирате съобщения, които ви са изпратени. 

alice% gpg --output revoke.asc --gen-revoke mykey
 [...]

Аргументът mykey трябва да бъде идентификатор на ключ. Той може да е ID номера на вашата основна двойка или всяка част от вашия потребителски идентификатор, която може да идентифицира тази двойка. Генерираният сертификат ще се намира в revoke.asc. Ако не използваме --output опцията резултатът от командата ще бъде изпратен към стандартния изход. Тъй като сертификатът не е много дълъг, вие може да го отпечатате и да го запазите някъде на сигурно място. Сертификатът не трябва да бъде съхраняван, някъде където други може да го достъпят, защото по този начин всеки може да го публикува и да направи вашия публичен ключ неизползваем.

Обмен на ключове

За да осъществите сигурна комуникация с други, вие трябва да размените своите публични ключове. Може да получите списък на ключовете във вашето хранилище чрез опцията --list-keys. 

alice% gpg --list-keys
 /users/alice/.gnupg/pubring.gpg
 ---------------------------------------
 pub  1024D/BB7576AC 1999-06-04 Alice (Judge) <alice@cyb.org>
 sub  1024g/78E9A8FA 1999-06-04

Извличане на публичния ключ

За да изпратите вашия публичен ключ, на ваш кореспондент, вие трябва първо да го извлечете. За това се използва опцията --export Тя има нужда от допълнителен аргумент, който идентифицира публичния ключ, който се извлича. Както и при --gen-revoke опцията, може да въведете номер на ключ или друга идентифицираща ключа информация. 

alice% gpg --output alice.gpg --export alice@cyb.org

По този начин ключът ще бъде съхранен в двоичен формат и това може да го направи неудобен за изпращане в емайл съобщение или за публикуване на уеб страница. За да бъде избегнато това неудобство се използва опцията --armor[2] която преобразува резултата в набор от ASCII символи. --armor option. 

alice% gpg --armor --export alice@cyb.org
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 Version: GnuPG v0.9.7 (GNU/Linux)
 Comment: For info see http://www.gnupg.org
 
 [...]
 -----END PGP PUBLIC KEY BLOCK-----

Добавяне на публичен ключ

За добавяне на публичен ключ се използва --import опцията. 

alice% gpg --import blake.gpg
 gpg: key 9E98BC16: public key imported
 gpg: Total number processed: 1
 gpg:               imported: 1
 alice% gpg --list-keys
 /users/alice/.gnupg/pubring.gpg
 ---------------------------------------
 pub  1024D/BB7576AC 1999-06-04 Alice (Judge) <alice@cyb.org>
 sub  1024g/78E9A8FA 1999-06-04
 
 pub  1024D/9E98BC16 1999-06-04 Blake (Executioner) <blake@cyb.org>
 sub  1024g/5C8CBD41 1999-06-04

След като ключът е добавен вие трябва да прецените доколко вярвате на този ключ. GnuPG използва мощен и гъвкав модел на доверието,който не изисква вие да вземете отношение към всеки ключ, който добавяте. Някои ключове, обаче, трябва да получат вашето лично доверие. Ключът се подписва (валидира) след като се провери отпечатъка (fingerprint) му. Отпечатъка на ключа може да се види с опцията --fingerprint ,но за да подпишете (да се доверите) на ключа вие трябва да го редактирате. 

alice% gpg --edit-key blake@cyb.org
 
 pub  1024D/9E98BC16  created: 1999-06-04 expires: never      trust: -/q
 sub  1024g/5C8CBD41  created: 1999-06-04 expires: never     
 (1)  Blake (Executioner) <blake@cyb.org>
 
 Command> fpr
 pub  1024D/9E98BC16 1999-06-04 Blake (Executioner) <blake@cyb.org>
 Fingerprint: 268F 448F CCD7 AF34 183E  52D8 9BDE 1A08 9E98 BC16

Отпечатъкът на ключа е хеш сума на самия ключ и отпечатъка на ключа, който сте добавили трябва да бъде сравнен с този, който сте получили от собственика на ключа. Това може да стане лично или по телефона или по какъвто и да е друг начин докато вие може да сте сигурни, че комуникирате с истинския собственик на ключа. Ако отпечатъка, който вие сте получили, съвпада с този, който ви е дал собственика на ключа, то вие може да сте сигурни, че притежавате правилното копие на ключа.

След като проверите отпечатъка, вие може да подпишете ключа. Тъй като подписването на ключа е едно от слабите места в криптографията с публичен ключ вие трябва да сте изключително внимателен и винаги да проверявате отпечатъка на ключа преди да го подпишете. 

Command> sign
 
 pub  1024D/9E98BC16  created: 1999-06-04 expires: never      trust: -/q
 Fingerprint: 268F 448F CCD7 AF34 183E  52D8 9BDE 1A08 9E98 BC16
 
 Blake (Executioner) <blake@cyb.org>
 
 Are you really sure that you want to sign this key
 with your key: "Alice (Judge) <alice@cyb.org>"
 
 Really sign?

Веднъж подписали ключа вие може да проверите другите подписи и да видиде вашия подпис. Всеки потребителски идентификатор ще има един или повече подписа на своите ключове, както и подписи от страна на всеки потребител, който е подписал ключа. 

Command> check
 uid  Blake (Executioner) <blake@cyb.org>
 sig!       9E98BC16 1999-06-04   [self-signature]
 sig!       BB7576AC 1999-06-04   Alice (Judge) <alice@cyb.org>

Шифриране и дешифриране на документи

И публичния и частния ключ имат своята роля при шифрирането и дешифрирането на документи. За публичния ключ може да се мисли като за отворен сейф. Когато ваш кореспондент шифрира за вашия публичен ключ той все едно поставя документа в сейфа и го затваря. За да бъде отворен сейфа е нужен вашия частен ключ и по този начин се гарантира, че вие сте единственият, който може да достъпи информацията. Казано накратко, само човекът, който притежава частния ключ, може да дешифрира документ, който е шифриран с комплементарния му публичен ключ.

Процедурата по шифриране и дешифриране е лесна следвайки този мисловен модел. Ако вие искате да шифрирате съобщение за Алис, вие трябва да го шифрирате с публичния й ключ и тя ще може да го дешифрира чрез нейния частен ключ. Ако Алис иска да ви прати съобщение, тя го шифрира използвайки вашия публичен ключ и след като го получите вие ще може да го дешифрирате с вашия частен ключ.

За да шифрирате документ използвате опцията --encrypt Вие трябва да имате публичния ключ на получателя на съобщението си. GnuPG очаква името на документа, който ще шифрира, ако не го намери там очаква съдържанието му от стандартния вход Шифрираното съдържание ще бъде изпратено към стандартния изход, освен ако не бъде използвана опцията --output. Документът също е компресиран за допълнителна сигурност. 

alice% gpg --output doc.gpg --encrypt --recipient blake@cyb.org doc

Опцията --recipient се използва за всеки получател като се указва и публичния ключ, който ще се ползва за шифрирането. Изпратения документ може да се дешифрира само от някой с частен ключ, който е от същата двойка, с чийто публичен ключ е шифрирано съобщението. Вие не можете да дешифрирате документ, шифриран от вас, освен ако не сте го шифрирали и за вашия публичен ключ.

За дешифриране се използва --decrypt опцията. Трябва да имате частния ключ, за който съобщението е било шифрирано. Подобно на процеса на шифриране, документът за дешифиране е вход, а изхода е дешифрирания текст. 

blake% gpg --output doc --decrypt doc.gpg
 
 You need a passphrase to unlock the secret key for
 user: "Blake (Executioner) <blake@cyb.org>"
 1024-bit ELG-E key, ID 5C8CBD41, created 1999-06-04 (main key ID 9E98BC16)
 
 Enter passphrase:

Документите също може да бъдат шифрирани и без използването на криптография с публичен ключ. Вместо това се използва симетричен шифър. Ключът се получава от паролата, която задавате при шифрирането. С оглед на осигуряване на по-голяма сигурност, тази парола трябва да е различна от тази, с която сте защитили своя частен ключ. Симетричното шифриране е полезно, когато паролата не трябва да се съобщава на други. Можем да шифрираме документ с помоща на симетричен шифър с --symmetric опцията. 

alice% gpg --output doc.gpg --symmetric doc
 Enter passphrase:

Създаване и проверка на подписи

Цифровия подпис удостоверява съдържанието и времето на създаване/промяна на документа. Ако документът бъде модифициран в последствие, проверката на подписа ще го покаже. Цифровият подпис може да изпълни същата роля като саморъчния подпис с допълнителното предимство, че е устойчив на подправяне. Примерно изходния код на GnuPG е подписан и така потребителите могат да са сигурни, че той не е променян след като е бил подписан от разработчиците.

Създаването и проверката на подписи използва двойката ключове за операция различна от шифриране и дешифриране. Електронния подпис се създава, като се ползва частният ключ на подписващия. Подписа се проверява чрез кореспондиращия му публичен ключ. Примерно Алис би могла да използва нейния частен ключ, за да подпише цифрово нейната последна публикация в списание посветено на неорганичната химия. Редакторът на списанието ще използва публичния ключ на Алис, за да провери дали наистина тази публикация идва от нея и дали не е била променена след като е била подписана. Друго последствие от използването на цифров подпис е, че е трудно да се отрече авторството върху подписан документ, тъй като това би означавало, че двойката ключове е компроментирана.

Опцията --sign is се използва за цифрово подписване. Документът, който трябва да бъде подписан се очаква от стандартния вход, а към стандартния изход се изпраща подписания документ. 

alice% gpg --output doc.sig --sign doc
 
 You need a passphrase to unlock the private key for
 user: "Alice (Judge) <alice@cyb.org>"
 1024-bit DSA key, ID BB7576AC, created 1999-06-04
 
 Enter passphrase:

Документът се компресира преди да бъде подписан и затова изхода е в двоичен формат.

Ако имате подписан документ, вие може да само проверите подписа или да проверите подписа и да възстановите оригиналния документ. За да проверите подписа използвайте --verify опцията. За да проверите подписа и възстановите документа използвайте --decrypt опцията. Документът, който бива проверяван се очаква на стандартия вход, а възстановения документ се изпраща към стандартния изход. 

blake% gpg --output doc --decrypt doc.sig
 gpg: Signature made Fri Jun  4 12:02:38 1999 CDT using DSA key ID BB7576AC
 gpg: Good signature from "Alice (Judge) <alice@cyb.org>"

Подписване в самия документ

Често цифровият подпис се употребява за подписване на емайл или usenet съобщения. При тях не е разумно да се компресира документа преди да бъде изпратен и тогава се използва опцията --clearsign По този начин съдържанието на документа се загражда и подписа се добавя към съобщението, но самото съобщение не се променя по никакъв начин. 

alice% gpg --clearsign doc
 
 You need a passphrase to unlock the secret key for
 user: "Alice (Judge) <alice@cyb.org>"
 1024-bit DSA key, ID BB7576AC, created 1999-06-04
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 [...]
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v0.9.7 (GNU/Linux)
 Comment: For info see http://www.gnupg.org
 
 iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1
 oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k
 =y6kj
 -----END PGP SIGNATURE-----

Прикачен подпис

Документът, който съдръжа подписа в себе си има ограничено приложение. Друга възможност е да се използва метода на създаване на прикачен подпис, който представлява отделен файл, съдържащ подписа. Този тип подпис се създава чрез опцията --detach-sig 

alice% gpg --output doc.sig --detach-sig doc
 
 You need a passphrase to unlock the secret key for
 user: "Alice (Judge) <alice@cyb.org>"
 1024-bit DSA key, ID BB7576AC, created 1999-06-04
 
 Enter passphrase:

За да бъде проверен подписа са нужни подписа и самия документ. Това става с --verify опцията. 

blake% gpg --verify doc.sig doc
 gpg: Signature made Fri Jun  4 12:38:46 1999 CDT using DSA key ID BB7576AC
 gpg: Good signature from "Alice (Judge) <alice@cyb.org>"

Молба за корекции

За успеха и полезността на проекта е изключително важно той да е максимално изчистен от грешки и достъпен за разбиране. Затова ви моля да изпращате всякви корекции като коментар тук или на моя емайл адрес.
Пейо Попов



<< Инсталиране на Pine под Debian GNU/Linux 2.0 | Инсталация на Oracle 10g под Linux x86 >>