Регистрация в мобильном приложении myDSS 2.0
Скачайте и установите приложение myDSS 2.0 на свой телефон.
Запустите мобильное приложение myDSS 2.0 и нажмите "Начать регистрацию".
Нажмите "Зарегистрировать онлайн".
Выберите сервис облачной подписи. "IT MONITORING. Электронная подпись Lite" или "IT MONITORING. Электронная подпись PRO".
IT MONITORING. Электронная подпись Lite — срок действия лицензии 14 дней (используется, когда электронная подпись выпускается на ФЛ).
IT MONITORING. Электронная подпись PRO — срок действия лицензии 1 год (используется, когда электронная подпись выпускается на ЮЛ).
Нажмите "Выбрать".
Укажите название профиля и нажмите "Далее".
Нажмите "Включить уведомления", разрешите отправку уведомлений и нажмите кнопку "Далее".
Установите 6-значный пин-код, если устройство поддерживает Face ID или использование отпечатка пальца, то приложение предложит вам их использовать.
Ваш профиль создан. Для подтверждения регистрации выберите профиль и сообщите менеджеру кодовое слово.
II этап:
На мобильном устройстве запустите приложение myDSS 2.0 и подтвердите создание профиля.
Далее введите пин-код или разрешите использование Face ID или отпечатка пальца.
Нажмите "Выпустить сертификат", далее нажимайте в любом месте для генерации случайных данных до тех пор, пока не сгенерируется запрос на сертификат.
III этап:
На мобильном устройстве запустите приложение myDSS 2.0 и войдите в профиль для установки сертификата.
Как привязать электронную подпись к приложению MyDSS
Для перехода на новую технологию сдачи отчетности необходимо скачать на ваш смартфон приложение MyDSS. Инструкция ниже:
1. Для загрузки приложения на телефон вы можете либо отсканировать QR-код:
Либо скачать приложение MyDSS в PlayМаркете или App Store со следующей иконкой:
2. После выпуска подписи перейдите в раздел Моя организация — Электронные подписи — QR-код:
Для привязки приложения откройте QR-код в сервисе Небо и с помощью смартфона отсканируйте его:
По смс вам поступит код авторизации , его нужно ввести.
3. Задайте имя ключа, как правило, указывают название организации.
4. Можно задать пароль (не короче 6 символов). Также пароль можно не вводить.
После регистрации устройства ключ будет добавлен и отобразится на экране мобильного приложения.
5. При отправке отчетов, писем и уведомлений о прочтении действие необходимо будет подтверждать в этом мобильном приложении.
Mydss как подписать документ в налоговую
myDSS поддерживает два сценария подтверждения (отклонения) операций:
Online — мобильное устройство пользователя имеет выход в интернет. Пользователю придёт Push-уведомление о необходимости подтвердить операцию. Мобильное приложение myDSS загрузит с сервера сведения об операции (сопровождающий текст и подписываемый документ). Пользователю необходимо ознакомиться с подписываемыми данными и выразить своё согласие (отказ) на подписание документа, нажав кнопку «Подтвердить» («Отказаться») в мобильном приложении.
Offline — мобильное устройство пользователя не имеет выхода в Интернет. В данном сценарии пользователю необходимо отобразить QR-код, содержащие сведения о подтверждаемой операции. После считавания QR-кода, пользователю в мобильном приложении отобразится код подтверждения (отмены), который необходимо будет ввести в интерфейс DSS вручную.
Внимание!
В Offline сценарии на мобильном устройстве пользователя не может быть отображён подписываемый документ. Отобразить возможно только сопровождающий операцию текст.
Последовательность шагов при подтверждение операции подписи:
Примечание
Подтверждение других оперций на Сервисе Подписи (создание запроса на сертификат, отзыв сертификата, подпись пакета документов и т.п.) состоит из аналогичной последовательности шагов — отличие в типе транзакции, создаваемоей на Сервисе Подписи.
Результатом подтверждения транзакции на Сервисе Подтверждения Операций является AccessToken, содержащий идентификатор подтверждённой транзакции. При подтверждении транзакции на Центре Идентификации у пользователя есть две стратегии поведения:
Синхронная — пользователь переодически опрашивает конечную точку /confirmation. Если в ответе Сервиса Подтверждения Операций флаг IsFinal выставлен в true, то ответ будет содержать перевыпущенный AccessToken. С данным AccessToken пользователь обратиться к Сервису Подписи для получения подисанного документа.
Последовательность действий при синхронном-online подтверждении
Асинхронная — пользователь ожидает оповещения о завершении транзакции на адрес CallbackUri , переданный в первом запросе на конечную точку /confirmation. После подтверждения (отклонения) транзакции на мобильном устройстве на адрес CallbackUri , придет оповещение о завершении транзакции. В случае успешного завершения транзакции пользователь должен повторно обратиться на конечную точку /confirmation для получения нового AccessToken.
Последовательность действий при асинхронном-online подтверждении
Последовательность действий при Offline подтверждении
Подтверждение операции на Сервисе Подписи
- Пользователю создана учётная запись в DSS;
- Пользователю назначена аутентификация через myDSS;
- Пользователю выпущен сертификат эдектронной подписи;
- На сервере DSS зарегистрирован OAuth20 клиент.
В подтверждении транзакции задействованы следующие сервисы DSS:
Конечная точка | Сервис | Описание |
---|---|---|
https:// / /oauth | Сервис Аутентификации. | Аутентификация пользователей для возможности обращений к Сервису Подписи |
https:// / /rest/api | Сервис Подписи | Создание транзакций и получение результатов, подтвержденной операции |
https:// / /confirmation | Сервис Подтверждения Операций | Подтверждение транзакций |
Примечание
У Администратора DSS необходимо получить значение параметров client_id и resource. resource — идентификатор Сервиса Подписи, имеет вид: urn:cryptopro:dss:signserver:
Примечание
Для отображения подписываемого документа в мобильном приложении на Центре Идентификации должны быть настроены плагины преобразования документов — см. раздел Отображение документов
Аутентификация пользователя на Центре Идентификации
В примере рассматривается авторизация с использованием учётных данных пользователя (логин/пароль). Подробная информация по протоколу аутентификации: The OAuth 2.0 Authorization Framework
- grant_type — тип разрешения, в данном сценарии равен password.
- password – пароль пользователя.
- resource – идентификатор Сервиса Подписи.
В заголовке Authorization HTTP-запроса клиент должен передать идентификатор OAuth-клиента и секрет (если используется): Authorization: Basic Base64( : )
Примечание
В примере значение параметр password оставлено пустым, так как пользователю в качестве первичной аутентификации назначен метод «Только Идентификация»
В случае успешной аутентификации ответ будет содержать:
- access_token — AccessToken, выпущенный Центром Идентификации DSS
- token_type — Тип токена
- expires_in — Время жизни токена в секундах
Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи и Сервису Подтверждения Операций.
HTTP-код | Ошибка | Описание |
---|---|---|
400 | invalid_client | OAuth-клиент не зарегистрирован или неверно указан clienID |
400 | unauthorized_client | OAuth-клиент использует незарегистрированный сценарий аутентификации (Flow) |
400 | invalid_request | Неверно сформирован параметр resource |
500 | An error has occurred | 1. Проверяющая сторона с идентификатором resource не зарегистрирована. |
Создание транзакции подписи на Сервисе Подписи
После прохождения аутентификации пользователь инициирует подписание документа. Для подтверждения любых операций на Сервисе Подписи используется метод /transactions В запросе необходимо указать:
- OperationCode — тип создаваемой транзакции.
- Parameters — параметры тразнакции.
- Document — подписываемый документ.
В заголовке Authorization HTTP-запроса клиент должен указать AccessToken полученный при аутентификации: Authorization: Bearer .
Идентификатор сертификата подписи CertificateID можно получить запросив список сертификатов пользователя, обратившись на конечную точку \certificates
Параметры создания транзакций других типов приведены здесь
В примере создаётся прикреплённая CAdES-BES подпись.
Сервис Подписи вернёт идентификатор созданной транзакции. Далее пользователю требуется подтвердить транзакцию на Сервисе Подтверждения Операций.
HTTP-код | Ошибка | Описание |
---|---|---|
400 | invalid_certificate | Неверный идентификатор сертификата |
400 | invalid_request | Неверно указаны параметры подписи |
Подтверждение транзакции подписи на Сервисе Подтверждения Операций
Для подтверждения транзакции, созданной на Сервисе Подписи, пользователь отправляет запрос содержащий:
- CallbackUri — адрес для оповещения о завершении транзакции (опционально).
- TransactionTokenId – идентификатор транзакции, созданной на сервисе подписи.
- Resource – идентификатор Сервиса Подписи.
- ClientId — идентификатор OAuth клиента.
- ClientSecret — пароль OAuth клиента (для неконфиденциальных клиентов данный параметр не указывается).
В заголовке Authorization HTTP-запроса клиент должен передать токен, полученный на первом шаге: Authorization: Bearer .
Параметр CallbackUri — опциональный, используется в асинхронном сценарии подтверждения транзакции.
При получении запроса Сервис Подтверждения Операций и сервис myDSS начнут процедуру подтверждения операции в мобильном приложении. В частности отправят Push-уведомление пользователю.
Ответ Сервиса Подтверждения Операций содержит:
Поле | Описание |
---|---|
Challenge | Запрос на выполнение аутентификационного испытания |
AccessToken | Маркер доступа. Заполняется при IsFinal — true |
ExpiresIn | Время жизни AccessToken в секундах. Заполняется при IsFinal — true |
IsFinal | Является ли данный ответ последним в процессе подтверждения. |
IsError | Содержит ли данный ответ ошибку обработки запроса. Заполняется при IsFinal — false |
Error | Ошибка обработки запроса. Заполняется при IsFinal — false |
ErrorDescription | Подробное описание ошибки обработки запроса |
Поле Challenge содержит:
Поле | Описание |
---|---|
Title | Текст, который вызывающая система может отобразить пользователю в своём интерфейсе |
TextChallenge | Дополнительные данные для подтверждения операции |
В поле TextChallenge содержится:
Поле | Описание |
---|---|
Image | QR-код для Offline подтверждения операции |
RefID | Идентификатор транзакции, созданной на Сервисе Подтверждения Операций |
ExpiresIn | Срок действия транзакции, созданной на Сервисе Подтверждения Операций |
AuthnMethod | Идентификатор метода используемый для подтверждения транзакции |
Примечание
RefId — Идентификатор транзакции, созданной на Сервисе Подтверждения Операций. Идентификатор необходимо будет использовать при последующих обращениях на конечную точку /confirmation.
Примечание
При обработке ответа Сервиса Подтверждения Операций вызывающее приложение должно смотреть на значение двух флагов: IsFinal и IsError .
Если получен ответ с IsError — true, то дальнейшее подтверждение транзакции не возможно.
Если получен ответ с IsFinal — false, то подтверждение транзакции ещё не завершено.
Дальнейшее взаимодействие с Сервисом Подтверждения Операций зависит от выбранного сценария:
Асинхронное подтверждение транзакции
Если в первом запросе к Сервису Подтверждения Операций пользователь указал CallbackUri , то после подтверждения операции на мобильном устройстве пользователя придёт оповещение о завершении транзакции.
Сообщение о завершении транзакции содержит:
- Result — результат подтверждения транзакции (success или failed)
- TransactionId — идентификатор транзакции на Сервисе Подтверждения операций ( RefId )
- Error — код ошибки
- ErrorDescription — описание ошибки
Примеры ответа на CallbackUri
Оповещение о подтверждении операции:
Оповещение об отказе (пользователь в мобильном приложении Отказался от подтверждения операции):
Оповещение об истечении строка действия транзакции.
Если пользователь подтвердил операцию на мобильном устройстве, необходимо обратиться на Сервис Подтверждения Операций для получения нового AccessToken. В запросе передаётся идентификатор RefId .
Ответ Сервиса Подтверждения Операций будет содержать новый AccessToken, который необходимо использовать для получения подписанного документа.
HTTP-код | Ошибка | Описание |
---|---|---|
400 | invalid_transaction | 1. Срок действия транзакции истёк 2. Передан неверный идентификатор транзакции ( RefId ) |
400 | transaction_pending | У пользователя есть неподтвержденная транзакция. |
Синхронное подтверждение транзакции
В синхронном режиме пользователь должен периодически опрашивать Сервис Подтверждения Операция, ожидая завершение подтверждения транзакции (флаг IsFinal = true).
Если подтверждение не завершено, то IsFinal — false
Если в ответе IsFinal — true, то Сервис вернул новый AccessToken.
HTTP-код | Ошибка | Описание |
---|---|---|
400 | invalid_transaction | 1. Срок действия транзакции истёк 2. Передан неверный идентификатор транзакции ( RefId ) |
Offline подтверждение транзакции
Offline сценарий может использоваться как альтернативный способ подтверждения или отклонения транзакции. Сценарий может использоваться когда мобильное приложение не имеет доступа в Интернет, либо по каким либо причинам не смогло загрузить с сервера данные транзакции (сопровождающий текст, подписываемый документ)
Интегрируемая система должна отобразить пользователю QR-код ( Image ), полученный при первом обращении к Сервису Подтверждения Операций, и предоставить пользователю интерфейс для ручного ввода кода подтверждения (отказа) транзакции.
Длина кода подтверждения (отмены) настраивается Администратором на сервере DSS. Минимальная длина кода подтверждения (отмены) — 6 цифр.
Если в ответе `IsFinal’ — true, то Сервис вернул новый AccessToken.
HTTP-код | Ошибка | Описание |
---|---|---|
400 | invalid_transaction | 1. Срок действия транзакции истёк 2. Передан неверный идентификатор транзакции ( RefId ) |
400 | authentication_failed | Передан неверный код подтверждения (отмены) |
Получение подписанного документа на Сервисе Подписи
Примечание
В заголовке Authorization HTTP-запроса клиент должен указать AccessToken полученный от Сервиса Подтверждения Операций: Authorization: Bearer .
Примечание
Если закрытый ключ сертификата защищён на ПИН-коде, то ПИН-код должен быть указан при обращении на конечную точку /documents
Для вашего удобства мы подготовили ответы на вопросы, которые часто поступают от пользователей сервиса Synerdocs.
Вопрос:
Как привязать сертификат и подписывать документы с помощью приложения “MyDSS”?
Ответ:
Для подписания документов в сервисе обмена Synerdocs с помощью облачной ЭП, необходимо мобильное приложение MyDSS для смартфона под управлением Apple iOS или Google Android. Оно обеспечивает криптографическую аутентификацию пользователей КриптоПроDSS, безопасное взаимодействие, отображение документа и подтверждение операций подписания. Это позволяет соответствовать требованиям к безопасности и использовать квалифицированную электронную подпись для подписания документов по технологии DSS. Ниже содержится порядок установки и использования приложения MyDSS при работе в Synerdocs. Для того чтобы иметь возможность подписывать документы, необходимо следующее:
1. Установка приложения MyDSS.
2. Аутентификация в Synerdocs.
3. Привязка сертификата ЭП к мобильному приложению MyDSS.
После подписания или отказа в подписании документа в Synerdocs необходимо подтвердить
операцию в приложении MyDSS.
1.Установка приложения MyDSS
Для работы приложения необходимо устройство под управлением операционной системы Google Android версии 4.0 и новее или Apple iOS версии 8.0 и новее.
1.1 Установка на iOS
1. На мобильном устройстве откройте приложение APP Store.
2. В строке поиска введите «MyDSS» и нажмите кнопку поиска.
3. В результатах поиска выберите приложение «MyDSS КриптоПро», последовательно нажмите на кнопки Загрузить и Установить.
После завершения установки на экране мобильного устройства появится значок установленного приложения:
1.2 Установка на Android
1. На мобильном устройстве откройте приложение Play Маркет.
2. В строке поиска введите «MyDSS» и нажмите кнопку поиска.
3. В результатах поиска выберите приложение «MyDSS КриптоПро» и нажмите на кнопку Установить. После завершения установки на экране мобильного устройства появится значок установленного приложения:
2. Аутентификация в Synerdocs
1. Откройте браузер и перейдите на сайт веб-клиента. Откроется страница «Аутентификация».
2. На закладке «По паролю» введите логин либо адрес электронной почты и пароль.
3. Нажмите на кнопку Войти.
В результате откроется страница веб-клиента Synerdocs. При первом входе в веб-клиент откроется окно с инструкцией привязки сертификата ЭП по технологии подписания DSS к мобильному приложению MyDSS с помощью QR-кода. Привяжите сертификат к приложению MyDSS.
При необходимости QR-код доступен повторно в профиле пользователя по кнопке Привязать сертификат. После привязки пользователь сможет подписывать и отправлять документы с использованием сертификата облачной ЭП по технологии подписания DSS.
3. Запрос нового QR-кода в личном кабинете
Если вы не успели активировать новый сертификат в течение 1 месяца с момента его выпуска, рекомендуем запросить новый QR-код. Для этого необходимо зайти в раздел Настройки -> Профиль -> Запросить новый QR-код.
Запрос нового QR-кода может занимать до 5 минут (в это время не рекомендуется обновлять страницу), после чего, SMS-сообщение с новым кодом для привязки приложения может прийти с задержкой до 20 минут, просьба учитывать это при отправке запроса. После отсканировать QR-код с помощью приложения на мобильном телефоне и ввести код из СМС.
4. Привязка сертификата ЭП к мобильному приложению MyDSS
1. На мобильном устройстве запустите приложение MyDSS.
2. Наведите камеру мобильного устройства на QR-код, который был получен при аутентификации в Synerdocs, и нажмите на кнопку Сканировать:
3. Укажите код активации, который был получен по СМС, а затем нажмите на кнопку Продолжить.
4. При необходимости задайте имя ключу авторизации и пароль для доступа к нему.
5. В окне с информацией о том, что ключ сохранен, нажмите на кнопку Закрыть.
В результате в мобильном приложении на вкладке «Управление ключами» появится информация о созданном ключе.
5. Подписание и отказ в подписании документов
Порядок подписания некоторых типов документов аналогичен, поэтому можно выделить группы:
- акты выполненных работ и товарные накладные;
- ДПТ, ДПРР, УПД, УКД;
- неформализованные документы;
- транспортные и товарно-транспортные накладные.
Подробнее о подписании каждого типа документов см. в справке Synerdоcs, раздел «Подписание документов».
Если используется облачный сертификат ООО «Астрал-М» по технологии подписания DSS, то при подписании или отказе в подписании документа в Synerdocs операция подтверждается в мобильном приложении.
6. Подтверждение операций по подписанию/отказа в подписании документа в приложении MyDSS
Если есть операции подписания, требующие подтверждения, в приложении MyDSS отобразится уведомление об этом. Чтобы подтвердить операцию:
1. В уведомлении нажмите на кнопку Подтвердить:
2. Если при активации ключа был задан пароль, укажите его.
3. Ознакомьтесь с информацией о документе, который необходимо подписать и нажмите на кнопку Подтвердить.
4. В уведомлении об успешном подтверждении операции нажмите на кнопку Продолжить.
Системные требования
СКЗИ КриптоПро CSP версии 5.0 функционирует в следующих группах программно-аппаратных сред:
- Windows 7/8.1/10/Server 2008 (x86, x64);
- Windows Server 2008 R2/2012/2012 R2/2016/2019 (x64).
- Mac OS X 10.9/10.10/10.11/10.12/10.13/10.14 (x64).
Приложение My Dss поддерживается смартфонами, работающими под управлением операционных систем:
- iOS, версии 8.0 и старше — подойдут большинство IPhone и IPad. Проверить версию iOS можно в «Настройках» смартфона: выберите пункт «Основные» — «Обновление ПО».
- Android, версии 4.0 и старше. Чтобы проверить версию операционной системы, зайдите в «Настройки» на своем устройстве и выберите пункт «О телефоне».
Запрос и выпуск сертификата
1. После одобрения выпуска сертификата Удостоверяющим центром (УЦ) на e-mail, указанный в анкете, автоматически будет отправлена ссылка для генерации ОКЭП.
2. Откройте браузер перейдите по указанной в письме ссылке.
3. Откроется страница «Запрос сертификата».
4. Нажмите «Продолжить» и дождитесь выполнения всех пунктов
5. Когда все пункты будут зачеркнуты, нажмите на клавиатуре клавишу F5 либо ссылку «обновив страницу»
6. В открывшемся окне необходимо скачать бланк для подписи, нажав на соответствующую кнопку:
7. Распечатайте и подпишите бланк сертификата.
8. Отсканируйте документ в хорошем качестве.
9. Загрузите скан-копию, нажав на кнопку «Загрузить».
10. Сертификат выдан.
ВАЖНО! Чтобы использовать Облачную электронную подпись завершите процедуру валидации!
11. Для валидации подписи вам необходимо дождаться писем из УЦ с секретным ключом и QR-кодом для приложения КриптоПро myDSS.
- Письмо №1 с темой: «КриптоПро DSS»
Код активации ключа в myDSS: 123456.
- Письмо №2 с темой: «Информация для входа в DSS»:
Уважаемый клиент! Данные для входа в личный кабинет пользователя облачной подписи ниже.
Логин: dss_123456789
Пароль: 12qwaszx
- Письмо №3 с темой: «QR-код для приложения myDSS»
Во вложении находится индивидуальный QR-код. Он нужен, что подключить Сертификат облачной электронной подписи к Вашему мобильному устройству.
Если возникнут вопросы или письма в течение часа вам не пришли, обратитесь в техническую поддержку удостоверяющего центра ITCOM: 8 (800) 333-07-30 доб. 2400
Установка приложения My Dss
В мобильном приложении myDSS вы подтверждаете действия, которые совершаете с помощью облачной электронной подписи (ОКЭП).
Приложение не хранит закрытый ключ электронной подписи, но оно создает его учетную запись — ключ DSS. С помощью него приложение обращается к серверу УЦ и работает с сертификатом электронной подписи.
1. Приложение myDSS нужно установить на смартфон или планшет владельца ОКЭП. Приложение бесплатное.
2. Чтобы установить приложение myDSS, найдите его в магазинах App Store или Google play. Скачайте на свой смартфон.
3. В приложении Play Маркет или Apple store, в поиске, найдите приложение myDSS и нажмите Установить, а после установки нажмите Открыть.
Настройка приложения myDSS
1. Запустите на мобильном устройстве установленное ранее приложение «КриптоПро myDSS».
2. На главном экране нажмите кнопку с изображением QR-кода.
3. На экране сканирования нажмите кнопку «Сканировать».
4. Наведите камеру мобильного устройства на QR-код, который Вы получили в разделе «Запрос и выпуск сертификата» пункт 11 данной инструкции.
5. Введите в мобильном приложении Код активации ключа в myDSS и нажмите кнопку «Продолжить».
6. Выберите, каким образом будет защищен ключ аутентификации. К примеру, ПИН-кодом (паролем).
7. По желанию задайте имя ключа (по умолчанию «Ключ 1»).
8. Задайте ПИН-код (Пароль) для доступа к ключу аутентификации. ПИН-код НЕ ДОЛЖЕН быть короче 6 цифр. Повторно введите ПИН-код (Пароль) и нажмите кнопку «Продолжить».
9. После регистрации устройства на сервере ключ будет добавлен и отобразится на экране мобильного приложения. Закройте мобильное приложение.
Настройка Крипто Про CSP 5.0
1. Windows: Откройте меню Пуск , в папке Крипто Про выберите пункт Инструменты Крипто Про / Mac OS: Найдите среди установленных программ CP Tools и запустите.
2. В окне программы нажмите раздел «Облачный провайдер» и укажите:
4. Нажимаем кнопку «Далее».
5. Во время первого входа система предложит вам изменить пароль для входа в личный кабинет облачной подписи. Для этого введите пароль, указанный в письме «Информация для входа в DSS», в графу Старый пароль, а в графы Новый пароль и Подтверждение пароля установите свой пароль и ОБЯЗАТЕЛЬНО ЗАПИШИТЕ ЕГО ИЛИ ЗАПОМНИТЕ.
Если пароль был изменен вами ранее, то предложения изменить пароль не поступит и нужно будет ввести ваш пароль.
6. Следующий шаг Аутентификация необходимо подтвердить операцию с помощью мобильного приложения My Dss.
7. Откройте приложение My Dss на телефоне, и в появившемся запросе нажмите Подтвердить
8. В результате успешной авторизации/смены пароля вы должны увидеть уведомление «Установка сертификатов завершилась успехом». Валидация сертификата завершена.
Подтверждение операции подписания документа
1. После подписания электронной подписью документа на экране смартфона появится предложение подтвердить операцию. Дождитесь PUSH-уведомления на Вашем мобильном устройстве об операции. Если PUSH-уведомление не приходит, просто откройте приложение «КриптоПро myDSS».
2. При входе в мобильное приложение «КриптоПро myDSS» нажмите кнопку «Подтвердить».
3. Введите ПИН-код (Пароль) доступа к ключу аутентификации и нажмите кнопку «Продолжить».
4. На экране мобильного устройства отобразится подписываемый документ и информация о нем. Убедитесь, что хотите подтвердить подпись именно этого документа и нажмите кнопку «Подтвердить».
5. Если операция подтверждена успешно, на экране появится соответствующее сообщение. Нажмите «Продолжить».
6. В случае успешного подтверждения операции браузер предложит скачать или открыть подписанный документ. Откройте его или сохраните на жестком диске.
Отдел технической поддержки
Системные требования к программно-аппаратным средствам:
- Установка СКЗИ КриптоПро CSP версии 5.0.
- Операционная система Windows 7/8.1/10/Server 2008 (x86, x64).
- Серверные ОС Windows Server 2008 R2/2012/2012 R2/2016/2019 (x64).
- Mac OS X 10.9/10.10/10.11/10.12/10.13/10.14 (x64).
Для установки приложения MyDss на смартфоне, он должен работать под управлением операционных систем:
- Android 7.0 и выше.
- iOS 8/9/10/11.
Запускаем приложение Play Маркет или Apple store в зависимости от типа вашего устройства. В форме поиске, введите myDSS и нажмите кнопку Установить. После окончания установки нажимаем на кнопку Открыть.
Запустите установленное приложение MyDss. Для начала работы вам предложат от сканировать QR-код. Приложение отправит запрос на доступ к камере телефона, нажмите Разрешить. Возьмите бланк сертификата, выданного вам в УЦ и отсканируйте напечатанный QR-код. Укажите имя сохраняемого ключа(Оно может быть любым, например: «Облачная подпись для Торгов»). Так же вам потребуется выбрать способ подтверждения (без пароля, пароль, отпечаток пальца, face ID). После всех этих действий приложение будет готово к работе.
Для начала работы с вашей облачной подписью необходима установленная ОС Windows 7, 8,8.1 или 10. Необходимо проверить, что у вашей Операционной Системы установлены все последние обновления. Для этого запустите Центр Обновления Windows и произведите поиск и обновления компонентов Windows.
Основным элементом для работы с облачной подписью является установленное и настроенное КриптоПро CSP 5.0.
- Скачиваем последнюю версию установочного файла КриптоПро CSP 5.0 с сайта разработчика КриптоПро.
- Запускаем скачанный Файл CSPSetup-5.0.exe и нажимаем кнопку Установить.Подробный процесс установки КриптоПро здесь.
- Скачайте корневой сертификат Минкомсвязи России и установите его в «Доверенные корневые центры сертификации».
- Установить корневой сертификат вашего УЦ в «Промежуточные центры сертификации». Инструкция по установке корневого сертификата Минкомсвязи и УЦ.
В операционной системе Windows: Нажимаем Пуск , переходим в папку Крипто-Про и выбираем пункт Инструменты Крипто-Про.
Далее переходим в раздел Облачный провайдер.
- Необходимо поменять текст в строке Сервер авторизации на адрес вашего сервера DSS(Адрес можно уточнить у вашего УЦ).
- Так же измените текст в строке Сервер DSS на адрес предоставленный вашим УЦ.
- Нажимаем на кнопку Установить сертификаты.
На следующем шаге укажите логин полученный вами в точке выдачи и нажмите кнопку далее.
Если это первый ваш вход в систему, то вам предложат изменить пароль для входа в личный кабинет облачной подписи. Чтобы это сделать укажите пароль полученный вами в точке выдачи. Вводим его в графу Старый пароль, а ниже указываем Новый пароль и Подтверждение пароля. После установки вашего нового пароля, обязательно запишите его.
Если вы уже изменяли пароль ранее, то предложения изменить пароль не будет.
Следующим действием нам потребуется пройти Аутентификацию. Потребуется подтвердить операцию с помощью установленного приложения MyDss. Запустите приложение MyDss на смартфоне, и в открывшемся запросе нажимаем Подтвердить. Если на телефоне нет интернет соединения, то выбираем Используйте офлайн-подтверждение. Сканируем приложением MyDss QR-код и указываем полученный код подтверждения на компьютере.
Конечным результатом успешной авторизации, должно стать уведомление Установка сертификатов завершилась успехом.
На этом установка и настройка облачной электронной подписи закончена.
Купить Электронную Подпись для любых целей вы можете в нашей компании. Срок выдачи один рабочий день.
Появление электронных подписей позволило оптимизировать многие бизнес-процессы и работу компаний. Информация о пользователе, записанная на USB-носитель сделала электронный документооборот быстрым и удобным.
Ею пользуются не только ИП и ООО, но и физлица, например, для входа на «Госуслуги» или сайт ИФНС, чтобы получить услугу государственных учреждений.
На смену ставшей привычной ЭП, пришла облачная электронная подпись (ОЭП), которая не требует записи ключа и сертификата на носитель (рутокен), и нет привязки к рабочему месту. Не все еще знают, что это такое, как ей пользоваться, и какие преимущества она дает.
Ввиду того, что нашими читателями, в основном, являются участники и организаторы торгов, рассмотрим этот вопрос с точки зрения участия в тендерах, и какие в этом плюсы. Дадим инструкцию по установке необходимых программ и приложений для компьютера и телефона, чтобы можно было подписывать документы облачной ЭП.
- Как стали использовать облачные электронные подписи (ОЭП)?
- Что такое квалифицированная ОЭП?
- Как работает ОЭП?
- Ответы на самые распространенные вопросы
- Как установить ОЭП и начать работать?
- Преимущества
Использование электронных подписей прочно вошло во многие сферы нашей жизни. В различных компаниях сотрудников переводят на электронный документооборот (ЭДО), что делает все процессы удобными и быстрыми. Для подписания документов (договоров, актов, ведомостей, бухгалтерских отчетов и т.д.) требуется наличие электронной подписи. С помощью нее также осуществляется вход в личный кабинет пользователя ЭДО.
В своей работе применяют ЭП онлайн-специалисты и фрилансеры, которые ведут свою деятельность легально и заключают договора с заказчиками. Физические лица могут приобрести ЭП и пользоваться услугами государственных учреждений: записываться на прием в ФНС, к врачу районной больницы, подавать заявления, справки, заходить на «Госуслуги».
Мы уже привыкли к электронной цифровой подписи (ЭЦП), которая записана на рутокен (флеш-накопитель), принадлежит одному конкретному владельцу и обеспечивает безопасность данных о нем. Сегодня аббревиатура ЭЦП уже не используется, так говорить неправильно. В обиход вошло новое сокращение – ЭП (электронная подпись). По своей сути, ЭЦП и ЭП – это одно и то же, однако в статье будем использовать новое общепринятое сокращение – ЭП.
На смену понятию электронной подписи, записанной на цифровой носитель, пришло понятие облачной электронной подписи (ОЭП), которая реализована с помощью современных технологий. Она не требует записи сертификата и ключа на какой-либо носитель, а хранится на специальном облаке, в связи с чем у пользователей возникает вопрос о ее надежности. В статье максимально подробно постараемся на него ответить.
Для ЭП на носителе необходима установка специальных программ на компьютер пользователя (СКЗИ) и дополнительных надстроек. В связи с тем, что на смену таким приложениям пришли облачные приложения, у IT-разработчиков появилось желание внедрить их в работу с ОЭП.
Не все до конца понимают, что такое «электронная подпись в облаке», а те понятия, которые даются на различных сайтах в интернете или на youtube-каналах блогеров, подходят для новичков и объяснению «на пальцах». С одной стороны, это хорошо, так как пользователь ЭП не должен иметь образование программиста и вникать в тонкости шифрования информации. Он просто подписывает документ, а как это происходит, как генерируется каждый отдельный код при подписании, интересно далеко не всем.
Что же такое ОЭП с научной точки зрения, расскажем ниже. Любознательным читателям это определение, а также весь материал данной статьи пригодится для расширения собственного кругозора.
На сайте компании «КриптоПро», которая занимается разработкой и внедрением программ и приложений для работы с ЭП дается формулировка ОЭП, которая, по нашему мнению, наиболее соответствует действительности:
«Электронная подпись в облаке (облачная электронная подпись) – это вычислительная система, предоставляющая через сеть доступ к возможностям создания, проверки ЭП и интеграции этих функций в бизнес-процессы других систем».
Эта формулировка не исключает возможности для ОЭП использовать и локальное средство ЭП. Например, используя КриптоПро DSS Lite, пользователь через веб-браузер может подписывать электронный документ с помощью средства ЭП, установленного на его компьютер или планшет. В этом случае ключ подписи остается у пользователя, и защищенность сведений обеспечивается за счет стандартных методов, которые объединены в привычную нам ЭП. Или, проще говоря, это облачная ЭП с локальным средством ЭП.
Другой вариант облачной ЭП получается при использовании средства ЭП, хранящегося на облаке. Чтобы не путать это понятие с первым, назовем такую цепочку «полностью облачной ЭП». В среде специалистов до сих пор не утихают споры по поводу ее безопасности, так как информация передается на облако. Известно, что ЭП должна принадлежать одному собственнику. Записанную на носитель подпись владелец может хранить, например, в сейфе, чтобы ограничить доступ к ней третьих лиц. А как обеспечивается безопасность на облаке? Могут ли его взломать мошенники? Как сами разработчики гарантируют конфиденциальность информации, размещенной на облаке, и имеют ли сами доступ к ней?
Вопросами защищенности облака занимаются «безопасники» и консультирующие их юристы. Сведения должны не просто попасть на облако, но и быть обработаны и сохранены. С локальным средством все понятно: ЭП находится в защищенном пространстве пользователя. Но для облачной ЭП такое пространство отсутствует. При этом ответственность за обеспечение конфиденциальности данных в каком-то смысле «размывается» между её собственником и поставщиком облачных услуг.
Некоторые пользователи не доверяют надежности облака, так как не до конца понимают механизмы его действия. На облако передается ключ ЭП, а это информация, которая конфиденциальна и принадлежит конкретному человеку – собственнику. Защищенность ключа зависит от уровня безопасности средств, которые используются при аутентификации, и от ответственности владельца.
Разработчики КриптоПРО внедрили программу КриптоПро DSS, которая в тестовом режиме испытывалась экспертами. В этот сервер передаются ключи и сертификаты пользователей, а чтобы получить к ним доступ, необходимо пройти аутентификацию, которая возможна только для одного лица – владельца.
Рассмотрим пример, характерный для участников торгов. Допустим, поставщик направляет свое предложение на участие в тендере. До появления ОЭП подписать документ невозможно было без установленного на компьютер пользователя плагина. Этот плагин и софт локального средства сообщались друг с другом и работали в неразрывной связке. Этот софт подключался к софту на USB-токене, который генерировал код (ключ). С помощью ключа транзакция заверялась и уже подписанная переходила в плагин на браузер.
Теперь вытащим из этой схемы флеш-накопитель: софт подключается к облачному хранилищу по защищенному каналу.
Одной из первых площадок, которая оценила возможности новых технологий и внедрила в свои процессы использование облачной ЭП, стала федеральная торговая площадка «Росэлторг».
А можно без софта на локальном компьютере?
Да, это возможно, если на ЭТП есть дополнительный сервер, который обрабатывает входящую информацию и выступает в роли этого самого локального средства. В этом случае пользователь может использовать любой браузер.
В чем отличие стандартной ЭП от облачной?
Оба эти варианта имеют общее ядро с сертификатом и уровнем безопасности. По своей сути, они аналогичны, просто меняется схема внутреннего API-шифрования при кодировке информации. В первом случае ключ извлекается из локального средства, а во втором – с виртуального (удаленного).
Для использования облачной ЭП тоже нужна авторизация?
Да. Однако теперь авторизация имеет два уровня защиты, и нет привязки к компьютеру. При этом авторизация для пользователя не вызовет никаких сложностей:
Таким образом, злоумышленникам трудно будет украсть Вашу подпись, так как для этого они должны еще иметь доступ к Вашему телефону или электронной почте, на которые придет СМС или письмо с паролем.
Где хранится сертификат на стороне удостоверяющего центра?
Каждый удостоверяющий центр имеет свое хранилище, которое называется HSM (hardware security module). Оно имеет защищенное пространство, которое поделено на закрытые ячейки. Массовый доступ к ним запрещен.
Проще говоря, пользователь авторизовался, создал запрос на формирование подписи, запрос попадает в HSM на подпись. Шифр подписи генерируется каждый раз при подписании нового документа. Поэтому электронная подпись – это защищенный объект, а ключ не доступен к просмотру.
HSM подтверждает право владельца подписать форму, как нотариус при сделке подтверждает, что вы – это действительно вы.
УЦ получают лицензию от ФСБ на право использования этого хранилища. HSM имеет многофакторную защиту и снабжено антивзломочными датчиками.
Как выглядит первое подключение?
Сначала нужно произвести нехитрую настойку на устройстве пользователя. Для этого вводится два адреса DSS-системы. В принципе, на этом настройка заканчивается.
Следующий этап – это авторизация на сервере. Собственник ОЭП указывает в полях персональные логин и пароль, которые он получил в удостоверяющем центре. После этого проходит двухэтапную авторизацию. Чаще всего, необходимо считать полученный QR-код и скачать.
Потом сканируется второй код со ссылкой на свою ячейку в HSM. Пользователь получает пин-код на подтверждение операции на свой телефон, идентифицируя себя. Затем нужно сменить пароль для входа.
Последующие операции происходят быстрее: ПИН отправляется push-уведомлением. Подразумевается, что если мобильное устройство защищено FaceID или считыванием отпечатка пальца, то второго уровня авторизации, совместно с указанием логина и пароля, вполне хватает для обеспечения конфиденциальности.
- при потере телефона нужно повторить цепочку с QR-кодами снова;
- заблокированный телефон без пин-кода бесполезен;
- пин-код без логина и пароля бесполезен.
Если клиент потерял «незапароленный» телефон, на котором хранилась фотография с логином и паролем (реальный случай из жизни), он может обратиться в УЦ и попросить заблокировать доступ до выяснения.
Как получить конверт с доступами к ОЭП?
Конверт может получить заявитель (директор организации, должностное лицо, ответственный сотрудник), явившись лично в удостоверяющий центр с паспортом.
Либо может прийти сотрудник с официальной доверенностью, соответствующей требованиям 63-ФЗ (об электронной подписи) и требованиям службы безопасности УЦ.
ОЭП широко используется, или пока это редкость?
Использование ОЭП – это уже массовое явление сегодня. Тысячи клиентов из разных субъектов РФ применяют в своей работе электронную подпись на облаке. Из них большинство пользователей – это юридические лица, на втором месте по популярности использования – ИП. Большинство клиентов – москвичи. Затем идут граждане из Санкт-Петербурга, Новосибирска, Хабаровска, Ростова-на-Дону.
Для работы на локальном компьютере потребуется:
Чтобы пользоваться ОЭП на мобильном устройстве, оно должно работать на базе операционных систем не ниже Android 7.0 или iOS 8/9/10/11. Кроме этого, нужно установить приложение MyDss
Установка и настройка на смартфоне приложения MyDss
- Зайдите в приложение Play Market или Apple Store (зависит от устройства, которое Вы используете).
- В поисковую строку вбейте «MyDss» и запустите установку приложения.
- После завершения скачивания нажмите кнопку «Открыть».
4. Для начала работы система уведомит вас о необходимости сканирования QR-кода. Предоставьте камере доступ к этому действию.
5. Считайте QR-код с сертификата, который получили в УЦ.
6. Придумайте имя для сохраняемого ключа, например, «ОЭП для торгов».
7. Выберите способ авторизации (с паролем, без пароля, отпечаток пальца, Face ID).
8. Программа готова к использованию.
Установка СКЗИ КриптоПро CSP 5
Чтобы пользоваться облачной ЭП потребуется наличие операционной системы Windows 7, 8, 8.1 или 10. Проверьте, что Ваша ОС подходит для работы с ОЭП. Для этого откройте «Центр обновлений Windows» и запустите поиск и обновления компонентов Windows.
Для работы с облачной подписью обязательно нужно скачать и настроить программу КриптоПро CSP 5.0.
- Установите актуальную версию программы КриптоПро CSP 5.0 с официального сайта создателя приложения.
- Откройте скачанный пакет CSPSetup-5.0.exe и нажмите клавишу «Установить».
- Скачайте корневой сертификат Минкомсвязи РФ и сохраните его в «Доверенные корневые центры сертификации».
- Установить корневой сертификат вашего УЦ в «Промежуточные центры сертификации».
Настройка КриптоПро CSP 5.0
- Нажмите «Пуск» в ОС Windows и найдите папку «Крипто-Про».
- Выберите пункт «Инструменты Крипто-Про».
3. Перейдите в раздел «Облачный провайдер».
Замена адреса DSS-системы
- Поменяйте адрес в строке «Сервер авторизации» на адрес Вашей системы DSS (его можно узнать в своем УЦ).
- В строке «Сервер DSS» также измените адрес на информацию, полученную в УЦ.
- Нажмите «Установить сертификаты».
4. Вбейте логин и нажмите «Далее».
5. При первом запуске программы система предложит придумать новый пароль для доступа в личный кабинет. Для этого укажите старый пароль, а ниже – новый пароль, затем подтвердите его. При повторном запуске изменять пароль не нужно.
Аутентификация в приложении myDSS
Следующим шагом потребуется выполнить аутентификацию. Действие выполняется в приложении MyDss c мобильного устройства.
- Откройте приложение MyDss на смартфоне.
- Подтвердите действие по запросу системы.
- Если нет возможности подключиться к интернету, то нажмите строку «Используйте офлайн-подтверждение».
- Отсканируйте QR-код и укажите его на компьютере.
Если Вы выполнили все действия правильно, то система уведомит об успешности процедуры. На экране появится надпись «Установка сертификатов завершилась успехом».
myDSS SDK iOS
Для работы с библиотекой необходимы Xcode 11 и версии новее.
- Скачайте и распакуйте архив из репозитория
- Добавьте фреймворк myDSSSDK.xcframework в основной проект в Project Settins -> [Target Name] -> General в секции Frameworks, Libraries and Embedded Content
- Дополнительные файлы ( config.ini и RndmBioViewControllerIPhone.xib ) добавьте в проект и прикрепите к приложению в Project Settins -> [Target Name] -> Build Phases в секции Copy Bundle Resources .
Сертификаты
Для взаимодействия с серверами в ресурсы приложения нужно поместить сертификаты. Они должны лежать в директории root-certs в формате PEM.
Одновременно может быть использован только один сертификат. Он указывается при инициализации библиотеки:
Инициализация
Инициализировать библиотеку нужно перед вызовом внутренних функций SDK. Можно выставить уровень логирования и указать тип корневого сертификата.
Структура
Основные классы для работы:
- DSSUsersManager: Создаёт и управляет учётными записями пользователя на устройстве
- DSSOperationsManager: Получает информацию и подписывает операции и документы
- DSSCertificatesManager: Управляет сертификатами пользователей
- DSSDevicesManager: Управляет устройствами, привязанными к учётной записи
- DSSPolicyManager: Получает информацию о сервере DSS
Начало работы
Перед тем, как начать подписывать документы и операции, нужно создать пользователя. Есть 3 способа это сделать:
- Создать онлайн с подтверждением
- Создать с использованием QR-кода
- Создать онлайн с привязкой к другому устройству
Создание пользователя онлайн с подтверждением
Пользователь создан и сохранён в хранилище, его статус — .installed . Теперь нужно дождаться, когда его статус на сервере DSS сменится на .notVerified . Чтобы проверить текущий статус:
Как только статус пользователя станет .notVerified , мы сможем его верифицировать:
При верификации может потребоваться QR-код. Это зависит от настроек политики сервера.
Теперь статус пользователя .active , с ним можно работать дальше.
Создание с использованием QR-кода
При создании пользователя данным способом потребуется отсканировать QR-код, сгенерированый сервером. После создания статус пользователя — .active , с ним можно работать дальше.
Создание пользователя онлайн с привязкой к другому устройству
Данный способ применяется, когда уже есть устройство с подтверждённым пользователем и нужно привязать новое устройство. Потребуется передать идентификатор данного пользователя на новое устройство.
Получить идентификатор можно у экземпляра пользователя:
На новом устройстве вызываем метод:
Мы создали нового пользователя, его статус — .approveRequired , требуется подтверждение с основного устройства. На экране отобразится QR-код, который нужно отсканировать основным устройством.
На основном устройстве вызываем метод processAwaitingDevice :
Далее, на новом устройстве проверяем статус:
Теперь новое устройство подтверждено, статус пользователя — .active и с ним можно работать на новом устройстве.