Digicert Code Signing - проблема підпису в застарілих ОС

Проблема

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

Помилка перевірки підпису автентикоду з новою перехресною міткою часу

У червні 2022 року DigiCert представив новий перехресний корінь «DigiCert Trusted Root G4» для вирішення проблем сумісності із застарілими клієнтами з міткою часу. Запровадження перехресного кореня полягало в тому, що сертифікат часової позначки зв’язувався з більш поширеним коренем, який уже був присутній у кореневих сховищах застарілих систем.

У рамках цієї зміни новий крос-корінь включав лише атрибут EKU Time Stamping (1.3.6.1.5.5.7.3.8). Оскільки цей перехресний корінь також використовуватиметься як частина ланцюжка цифрового підпису, Windows не зможе перевірити ланцюжок сертифіката підпису коду через обмежений EKU.

Під час перевірки даних цифрового підпису на застарілих платформах можуть з’явитися помилки, подібні до наведених нижче:

"Сертифікат недійсний для запитаного використання"

"Здається, цей сертифікат недійсний для вибраної мети"

-------------

Рішення

Щоб вирішити цю проблему, DigiCert опублікував новий тимчасовий міжкореневий центр сертифікації. Для використання цього нового ЦС потрібно змінити процес підписання.

Це тимчасовий обхідний шлях для вирішення цієї проблеми, створено ще один крос-корінь спеціально для використання з цифровим підписом. Він містить правильний код підпису (1.3.6.1.5.5.7.3.3) EKU для проходження перевірки підпису Windows.

 

Ви можете завантажити його тут: digicert-g4-to-haevrca-codesigningcrosscert.crt

 

CodeSigning Cross Root

Serial: 0fd1bbca796bd7f8dd4c82e10a9a9631

Valid From: Jan 13 00:00:00 2022 GMT

Valid To: Nov 9 23:59:59 2031 GMT

Новий ICA «DigiCert Trusted Root G4» був перехресно підписаний «DigiCert High Assurance EV Root CA» лише з кодовим підписом EKU.

 

Timestamping Cross Root

Serial: 01240afb1e380b8a16f14b719df4d3c0

Valid From: Jun 9 00:00:00 2022 GMT

Valid To: Nov 9 23:59:59 2031 GMT

Новий ICA «DigiCert Trusted Root G4» був створений і перехресно підписаний «DigiCert Assured ID Root CA» лише з міткою часу EKU.

 

Підписання коду з новим перехресним підписом проміжного ICA повинно вирішити проблему. Якщо для підпису коду використовується Signtool, передайте параметр /ac у команді підпису:

signtool sign /ac DigiCert-G4-to-HAEVRCA-CodeSigningCrossCert.crt /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a "c:\path\to\file_to_sign.exe"

Переконайтеся, що файл було правильно підписано за допомогою цієї команди: signtool verify /pa signed_file.exe

 

Джерело: https://knowledge.digicert.com/solution/authenticode-signature-verification-fails-with-new-timestamping-cross-root.html?om_ext_cid=dc_email_7014z000001p3BtAAI_10783&mth=July%2C%202022

   

Certum блокує РФ

Польський Certum CA призупинили продаж наших послуг і продуктів під брендом до Російської Федерації та Республіки Білорусь - це рішення також стосується діяльності з продажу, яку здійснюють партнери Certum, які видавали сертифікати СЦ клієнтам у цих країнах.
Certum призупинили видачу нових сертифікатів SSL/TLS для доменів .RU і .BY, а також для компаній, зареєстрованих в Російській Федерації або Республіці Білорусь.
Certum CA призупинили видачу інших кваліфікованих і некваліфікованих сертифікатів для компаній, організацій і громадян з Російської Федерації та Республіки Білорусь.
У зв’язку з динамічною ситуацією та можливістю нових економічних санкцій з боку Європейського Союзу, також враховується сценарії, коли всі сертифікати, видані на даний момент для вищеописаних випадків, можуть бути відкликані та доступ до послуг Certum буде обмежено та заблоковано.
Слава Україні! Дякуємо Certum!
   

Digicert блокує РФ

З 10 березня 2022 року о 20:00 год. MST (11 березня, 3:00 ранку UTC) DigiCert призупинив видачу та перевипуск усіх типів сертифікатів, пов’язаних із Росією та Білоруссю. Це включає призупинення видачі та переоформлення сертифікатів для доменів верхнього рівня, пов’язаних з Росією та Білорусією, зокрема .ru, .su, .by, .рф та інших, а також організаціям з адресами в Росії чи Білорусі. Крім того, DigiCert наразі не приймає платежі в рублях.
Слава Україні! Дякуємо Digicert!
https://knowledge.digicert.com/solution/Embargoed-Countries-and-Regions.html
   

SECTIGO блокує РФ

Обмеження SECTIGO для Росії/Білорусі
Починаючи з 3 березня 2022 року Sectigo вирішив заблокувати всі замовлення з Росії та Білорусі. Це означає, що Нові замовлення та перевипуск сертифікатів не оброблятимуться для доменів верхнього рівня .ru, .by та .рф, а також усіх замовлень організацій, які мають Росію/Білорусь як країну в даних ORG/Admin/Tech.
Це також стосується сертифікатів GoGetSSL. Наразі Digicert (Thawte, RapidSSL, GeoTrust) все ще дозволяє замовлення.
Слава Україні! Дякуємо SECTIGO !
https://support.comodoca.com/articles/Knowledge/Banned-Country-List-1527076085907
   

До уваги користовачів сертификатів підпису документів PDF AATL GlobalSign

С 14 октября 2020 года GlobalSign будет использовать новый центр сертификации для сертификатов подписи документов AATL.

Эти изменения вносятся после того, как отрасль центров сертификации была предупреждена о последствиях для соответствия, связанных с отказом от включения выдающих ЦС с поддержкой TLS в соответствующие отчеты аудита, и включение определенного расширения (использование расширенного ключа подписи OCSP) в сертификаты ЦС для определенных условий, непреднамеренном соответствием и последствий для безопасности.

Эта проблема затрагивает также центры сертификации AATL «GlobalSign CA 2 для AATL», «GlobalSign CA 3 для AATL», «GlobalSign CA 4 для AATL» и «GlobalSign CA 6 для AATL».

Обратите внимание, что не было взлома ключа или нарушения безопасности, изменение выполняется исключительно в контексте устранения проблемы соответствия и устранения любого потенциального  риска безопасности.

GlobalSign будет переходить на новый AATL ICA в рамках планов компании по исправлению ситуации в соответствии с базовыми требованиями форума CA / B и GlobalSign CPS.

Если в настоящее время у вас есть какие-либо сертификаты AATL, выпущенные перечисленными выше центрами сертификации AATL, будьте уверены, что на данный момент ваши сертификаты останутся действительными, и любые действия по отзыву в рамках подготовки к событию отзыва 31 декабря 2020 года будут своевременно переданы всем затронутым клиентам.

Примечание. Подписи AATL, применяемые к PDF-файлам, которые включают встроенные проверки отзыва (например, OCSP или CRL, что часто встречается при использовании Adobe Acrobat для подписи), останутся действительными даже после отзыва.

Уведомление для клиентов HSM или приложений для пользовательской подписи:

Если вы используете развертывание HSM, то есть храните свой закрытый ключ в HSM, которым вы управляете локально или в облаке, обратите внимание, что вам потребуется обновить иерархию доверия.

Начиная с 14 октября 2020 г., вам нужно будет установить новый Промежуточный центр сертификации под названием "GlobalSign GCC R6 AATL CA 2020" расположен здесь

Обратите внимание, что новый ICA выдается центром сертификации GlobalSign для AATL - SHA384 - G4 в настоящее время используется для GlobalSign CA 4 для AATL, и поэтому он должен оставаться частью вашей иерархии сертификатов.

Если вы вручную задали URL-адрес OCSP как часть пользовательского приложения или конфигурация системы (вместо использования URL-адреса OCSP, указанного в расширении AIA сертификатов EE), вам также потребуется обновить конфигурацию системы для нового URL-адреса OCSP http: // ocsp.globalsign.com/gsgccr6aatlca2020.

   

SSL FATCA для українських банків і фінансових установ

1 липня 2014 року набрав чинності Закон Сполучених Штатів Америки «Про податкові вимоги до іноземних рахунків» (далі - FАТСА), що містить вимоги до іноземних фінансових організацій - Інформаційна довідка щодо імплементації положень Закону США «Про податкові вимоги до іноземних рахунків» (FATCA)

Міністерство фінансів України повідомило всіх фінансових агентів України про перенесення у зв’язку з COVID-19 строків подання звітів про підзвітні рахунки в рамках Угоди FATCA за 2019 податковий рік для компетентних органів країн, що звітують за моделлю IGA 1, до яких відноситься і Україна, на період до 31 грудня 2020 року. Ознайомитись з ним можна за посиланням.

Також,  Міністерство фінансів США, листом від 07.08.2020, повідомило, що  термін подання звітів для всіх звітуючих країн, у тому числі для України, подовжено до 31 грудня 2020 року.

Для ДПС України, яка є компетентним органом для цілей автоматичного обміну інформацією в рамках Угоди FATCA,  строки подання до Служби внутрішніх доходів США звітів за 2019 податковий рік подовжено до 31 грудня 2020 року.

Зважаючи на те, що у Кодексі встановлений термін звітності для фінансових агентів, який забезпечує компетентному органу місячний термін для обробки та перевірки наданої інформації, кінцевий строк подання фінансовими агентами звіту про підзвітні рахунки подовжуються до 1 грудня 2020 року. До цієї дати фінансові агенти повинні подати через портал IDES (International data exchange service – Міжнародна служба обміну даними) до ДПС України (центрального органу виконавчої влади, що реалізує державну податкову політику) звіти про підзвітні рахунки за 2019 рік та інформацію, яка стосується звітних періодів з 2014 по 2018 роки, відповідно до положень Угоди FATCA.

Відповідно до зазначеного Порядку заповнення і подання фінансовими агентами звіту про підзвітні рахунки відповідно до Угоди FATCA фінансові агенти подають звіти до ДПС через Міжнародну службу обміну даними (МСОД – платформа IDES). Порядок та методика використання платформи IDES докладно описані в Інструкції користувача (Публікація Служби внутрішніх доходів США 5190 (далі – Публікація СВД 5190).

Порядок та методика використання платформи IDES докладно описані в Інструкції користувача (Публікація Служби внутрішніх доходів США 5190 (далі – Публікація СВД 5190). (переклад українською)

Для підключення до фінансовим агентам необхідно:

  • Придбати SSL-сертифікат (типи сертифікатів та центри сертифікації наведено у розділі 3 Публікації СВД 5190 або за посиланням. Подробнее про получение SSL сертификата для Fatca читайте в нашей статье
  • мати GIIN (ідентифікаційний номер, що надається Службою внутрішніх доходів США для цілей звітування відповідно до Угоди FATCA).
  • Інформація щодо реєстрації для цілей звітування відповідно до Угоди FATCA та одержання коду GIIN розміщена на вебсайті Служби внутрішніх доходів США (https://www.irs.gov/businesses/corporations/fatca-foreign-financial-institution-registration-system).
  • здійснити реєстрацію (процедуру реєстрації викладено у розділі 4 Публікації СВД 5190).

Звіти фінансових органів вважаються наданими і отриманими Службою внутрішніх доходів США у день, коли ДПС України підтвердить, і, таким чином, розкриє інформацію у IDES Службі внутрішніх доходів США, а інформація, яка передається Службою внутрішніх доходів США, вважається наданою і отриманою ДПС України у день, коли вона є доступною для завантаження з IDES (розділ 11.6 Публікації СВД 5190).

Всі проблемні питання, пов’язані із FATCA, фінансові агенти можуть направляти на адресу електронної пошти info_FATCA@tax.gov.ua, відповіді на які будуть розміщені на банері «FATCA» https://tax.gov.ua/baneryi/fatca/pitannya-vidpovidi/ або надані безпосередньо особі, яка направила запит електронною поштою.

 

Джерело

upd 20.11.2020: Перенесення строків звітування про підзвітні рахунки (FATCA)

Листом від 12 листопада 2020 року Служба внутрішніх доходів США повідомила Міністерство фінансів України про перенесення для України строку подання звітів про підзвітні рахунки за звітні періоди з 2014 року по 2019 рік на 30 вересня 2021 року.

Враховуючи зазначене та положення пункту 69.8.3 статті 69 Податкового кодексу України фінансові агенти мають подати до ДПС України через систему IDES звіти про підзвітні рахунки за 2020 рік та інформацію, яка стосується звітних періодів з 2014 по 2019 роки, до 1 вересня 2021 року.

------------

оновлено 19.11.21

Джерело  https://tax.gov.ua/media-tsentr/novini/527408.html

Інформація на сайті міністерства фінансів

Служба внутрішніх доходів США (далі – СВД США) надала інформацію щодо оновлення її цифрового сертифікату. Термін дії цифрового сертифікату FATCA СВД США закінчиться наприкінці грудня 2021 року. Щоб запобігти перериванням у поданні звітів, СВД США буде відкрито новий сертифікат/ключ, доступний для фінансових агентів для завантаження починаючи з 3 грудня 2021 року з 07:00 EST (14:00 за київським часом).

Щоб заявники мали можливість завантажити новий сертифікат, СВД США планує сповістити їх через інформаційний бюлетень FATCA.

Після 3 грудня 2021 року отримані файли звітів з FATCA мають бути закодовані новим відкритим сертифікатом, інакше ці файли створюватимуть помилки на рівні файлу «Помилка перевірки підпису».

   

Digicert игнорирует поле OU в сертификатах

31 августа DigiCert прекратили поддержку поля «Организационная единица» (OU), чтобы упростить заказ сертификатов.

Поле OU позволяет хранить дополнительные метаданные в сертификате, однако его предполагаемое назначение крайне ограничено и требует длительной и глубокой проверки со стороны сертификационного центра.

Чтобы избежать путаницы вокруг этого необязательного поля и сократить время проверки, Digicert принял решение удалить его из будущих процессов заказа.

Вскоре поле OU больше не будет отображаться в формах заказов, будет игнорироваться в запросах API и будет удалено во всех новых, обновленных и повторно выпущенных общедоступных сертификатах TLS.

Это изменение не повлияет на ранее выданные сертификаты с действительным полем OU. Это не влияет на частные сертификаты TLS или другие типы сертификатов, отличных от TLS.

   

До уваги власників 2-річних SSL сертифікатів.

 

З 27 серпня для діючих дворічних SSL сертифікатів після перевипуску буде скорочуватись термін дії до 397 днів (без відшкодування вартості втраченого терміну). Будьте уважні та не перевидавайте діючі дворічки SSL без необхідності.

Нагадуємо, що з 1 вересня SSL сертифікати видаватимутся виключно терміном дії 1 рік. Сертифікаційні центри припиняються видачу 2-річних сертифікатів невалідованим організаціям з 12 серпня, валідованим 27 серпня.

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

   

С 1 сентября 2020 года SSL сертификаты только на 1 год

SSL сертифікати тільки на 1 рік

Що це для користувачів сертифікованих веб-сайтів? Що стосується вашого веб-сайту Safari, ви більше не можете публічно надсилати сертифікати TLS, а термін, який потрібно було пройти 398 днів після 30 серпня 2020 року. Будь-які сертифікати, видані до 1 вересня 2020 року, залишаються справді незалежними від терміну дії (до 825 днів). Сертифікати, які використовують не для публічної довіри, все ще можуть бути розпізнані до максимальної терміни, яка вимагає 825 днів.

Чому так сталося.

Як правило, у форумі CA / Browser (CA / B) у Братиславі, Словаччина, Apple оголосила, що з 1 вересня почала використовувати у своєму браузері Safari нові новини, що публікуються публічно, щоб отримати сертифікати TLS, які мають не більше 398 днів. Це супроводжує довгу історію, яка обговорюється у Форумі CA / B, яка працювала над скороченням терміну службового сертифіката та покращувала безпеку, одночасно використовуючи необхідні власні користувачі, переходячи на короткі терміни.

У серпні 2019 року Google представив бюлетень для голосування на форумі CA / B SC22, щоб зменшити терміни сертифікатів TLS до одного року. Організатори розглядали цю пропозицію із своїми власними замовниками та публікували інших користувачів коментарів, які в основному підтримували протидії, а також додавали додаткові результати, необхідні ІТ-команди для скорочення коротких термінів. Будучи не ввімкненим у Форумі, що зазначило, що максимальний термін сертифікатів підтверджувався протягом двох років.

Час від часу можна було отримати сертифікати SSL з максимально можливим терміном три роки. Кілька років тому вони скоро до двох років. Швидкий перехід до цього Apple, який підкреслює те, що не вдалося зробити головному SC22: скоро перевірити сертифікат до одного року.

Чому Apple в односторонньому випадку працювала за короткою терміном, що скорочує термін дії сертифікатів? Їх речник вважає, що це "захищений користувач". З попередньою дискусією Форум CA / B ми знаємо, що довший термін служби сертифікованих довіряє склад у заміні сертифікатів у великих інцидентах, які мають бути впевнені. Apple очевидно хоче використати системи, які не можуть швидко реагувати на основні загрози, представлені сертифікатами. Короткотривалі сертифікати покращують безпеку, при цьому вони зменшують експозицію вікна, і сертифікат TLS надсилається. Також ми підтримуємо нормальне функціонування в організації, використовуючи те, що оновлено ідентифікують, як і колись, і адресу та активні домени. Як і будь-яке, котрий підкреслив, скорочення терміну життя запросив бути суттєво перед твердими, необхідними для користувачів сертифікатів для досить важливих.

Зараз Apple представила свою офіційну інформацію про основні знання про цю тему https://support.apple.com/en-us/HT211025.

   

Постквантовая криптография

Подготовка к квантово-безопасному будущему.

Почти все цифровые коммуникации защищены тремя криптографическими системами:

  1. шифрование с открытым ключом
  2. цифровые подписи
  3. обмен ключами

В современной инфраструктуре открытых ключей эти системы реализованы с использованием асимметричных криптографических алгоритмов RSA или ECC. Криптография RSA и ECC основывается на так называемом предположении о вычислительной жесткости - гипотезе о том, что теоретическая числовая задача (такая как целочисленная факторизация или проблема дискретного логарифма) не имеет эффективного решения. Однако эти предположения основывались на вычислительной мощности классических компьютеров.

В 1994 году Питер Шор продемонстрировал, что асимметричные алгоритмы, основанные на предположении о вычислительной жесткости, могут быть очень легко нарушены с помощью достаточно мощного квантового компьютера и специального алгоритма, позже названного алгоритмом Шора. Фактически, квантовый компьютер с достаточным количеством кубитов и глубиной контура мог мгновенно взломать асимметричные алгоритмы. Исследование, опубликованное ASC X9 Quantum Computing Riz Study Group, оценило эти точные требования.

AlgorithmRequired logical qubitsRequired circuit depth
RSA-2048 4700 8 10^9
ECC NIST P-256 2330 1.3 10^112

Для подробного объяснения алгоритма Шора и того, как квантовые компьютеры могут нарушать асимметричное шифрование, смотрите видео.

По оценкам большинства экспертов, в течение следующих 20 лет будет построен достаточно мощный квантовый компьютер с требуемыми кубитами и глубиной контура для взлома ключей RSA и ECC.

Два десятилетия могут показаться долгим, но имейте в виду, что индустрия PKI, которую мы знаем сегодня, заняла примерно столько же, чтобы попасть в наше настоящее. Согласно проекту постквантовой криптографии NIST, «вряд ли будет простая « вставная » замена для наших нынешних криптографических алгоритмов с открытым ключом. Потребуются значительные усилия для разработки, стандартизации и развертывания новых постов». -квантовые криптосистемы. "

Вот почему DigiCert начал работать с несколькими игроками пост-квантовой индустрии, чтобы помочь создать экосистему PKI, которая является квантово-безопасной и достаточно гибкой, чтобы противостоять любым будущим угрозам.

Квантовые векторы атаки

Первым шагом для эффективной защиты от этих будущих угроз является выявление различных векторов атак, создаваемых постквантовым ландшафтом угроз.

TLS / SSL рукопожатие

Квантовые компьютеры представляют наибольшую угрозу для асимметричных криптографических алгоритмов. Это означает, что криптографическая система, используемая для цифровой подписи сертификатов и обработки начального рукопожатия SSL / TLS, является потенциальным вектором атаки.

К счастью, и NIST, и ASC X9 утверждают, что симметричные криптографические алгоритмы (такие как AES), используемые для создания сеансовых ключей для защиты данных при передаче после первоначального рукопожатия TLS / SSL, кажутся устойчивыми к атакам квантовых компьютеров. Фактически, для защиты от квантовых компьютерных атак достаточно удвоить длину в битах симметричного ключа (например, с AES-128 до AES-256). Это связано с тем, что симметричные ключи основаны на псевдослучайной строке символов и требуют использования атаки методом грубой силы или использования какой-либо известной уязвимости для взлома шифрования, в отличие от использования алгоритма (например, алгоритма Шора) для нарушения асимметрии криптография.

Эта упрощенная диаграмма квитирования TLS / SSL показывает, какие действия подвергаются риску квантовых компьютерных атак, а какие безопасны.

TLS / SSL  handshake с использованием современных асимметричных криптографических алгоритмов (RSA, ECC) и AES-256


Этот вектор атаки угрожает начальной связи с серверами с использованием цифровых сертификатов конечных объектов. Хотя это все еще довольно большая угроза, это, вероятно, не самый опасный вектор атаки.

Даже при наличии достаточно мощного квантового компьютера ресурсы, необходимые для вычисления закрытого ключа сертификата, все еще значительны. Из-за этого можно с уверенностью предположить, что ни один цифровой сертификат конечного объекта не является настолько важным, чтобы оправдать квантовую атаку. Не говоря уже о том, что достаточно просто изменить ключ и заново выдать сертификат конечного объекта.

Сеть доверия

Вероятно, наиболее опасным вектором атак со стороны квантовых компьютеров является цепочка доверия (цепочка сертификатов), используемая цифровыми сертификатами. Асимметричные криптографические алгоритмы RSA и ECC используются на каждом уровне цепочки доверия - корневой сертификат подписывает себя и промежуточный сертификат, а промежуточный сертификат подписывает сертификаты конечного объекта.

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

Квантово-безопасные криптографические системы

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

С конца 2016 года проект NIST Post-Quantum Cryptography (PQC) возглавляет исследовательские работы по квантово-безопасным криптографическим системам. Пока что они определили 26 постквантовых алгоритмов в качестве потенциальных кандидатов на замену. Однако, прежде чем эти криптографические системы будут готовы к стандартизации и развертыванию, необходимо провести гораздо больше исследований и испытаний.

Согласно срокам проекта NIST PQC, еще один раунд исключений произойдет где-то между 2020 и 2021 годами, а проекты стандартов станут доступны между 2022 и 2024 годами.

Планирование постквантового будущего

Этот переход должен произойти задолго до того, как будут построены какие-либо крупномасштабные квантовые компьютеры, чтобы любая информация, которая впоследствии была скомпрометирована квантовым криптоанализом, перестала быть чувствительной, когда происходит такой компромисс. (Проект NIST PQC)

Из-за времени, которое потребуется для разработки, стандартизации и развертывания постквантовых криптографических методов, DigiCert начал тестирование жизнеспособности встраивания постквантовых алгоритмов в гибридные сертификаты с использованием этого проекта IETF.

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

  • Непосредственные шаги, которые вы можете предпринять, чтобы подготовиться к постквантовому будущему
  • Подробности о гибридных сертификатах и как они могут защитить существующие системы
  • Ресурсы PQC и руководство по настройке

 

 

   
Страница 1 из 4