Познакомьтесь с новыми API шифрования/дешифрования, предлагаемыми Lotus Notes и Domino 7.0.

Филипп Лохер, инженер-программист, IBM

Филипп Лохер (Phillipe Loher) - инженер-программист в области обмена сообщениями Lotus и продуктов для совместной работы. В его текущие проекты входят Domino, унифицированные взаимодействия и мобильная функциональность. Филипп живет в окрестностях Boston, любит играть в теннис и производить вино.



26.07.2005

В данной статье мы рассмотрим много различных функциональных возможностей, связанных с новыми API шифрования/дешифрования, в Notes/Domino 7 Notes. Мы обсудим, как бизнес-партнеры и другие Notes-разработчики могут реализовать в своих программах возможность читать и создавать Notes-шифрованные и S/MIME-шифрованные сообщения. Существует бесчисленное множество сценариев, когда бизнес-партнеры и разработчики могут захотеть реализовать возможность просматривать и/или создавать зашифрованные документы в своих приложениях. В данной статье приведен обзор критичных технических и административных подробностей, необходимых для реализации этих и других защитных функциональных возможностей Notes/Domino 7.

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

В данной статье предполагается, что вы являетесь опытным разработчиком приложений Notes/Domino с хорошими знаниями системы защиты Notes/Domino. Также желательно иметь представление о модели сертификатов безопасности Domino. Информация о системе защиты и других функциональных возможностях Notes/Domino 7 приведена в статьях developerWorks: Lotus "Новые функциональные возможности Lotus Domino 7.0 Beta 4" и "Новые функциональные возможности Lotus Notes и Domino Designer 7.0 ".

Обзор API системы защиты Notes/Domino 7

Новые методы API системы защиты являются частью C-библиотеки среды исполнения Notes/Domino 7. При помощи библиотеки среды исполнения Notes/Domino 7 к этим API могут обращаться приложения, способные использовать NRPC-вызовы.

До появления новых API в Notes/Domino 7 (подмножество которых было также представлено в Notes/Domino 6.5x) Notes-приложение могло читать/создавать Notes-шифрованные и S/MIME-шифрованные документы при помощи API NSFNoteCopyAndEncrypt и NSFNoteDecrypt соответственно. Существует несколько причин, почему этого метода может быть недостаточно для Notes-приложения. Во-первых, приложение должно переключиться на контекст пользователя, выполняющего шифрование/дешифрование путем вызова SECKFMSwitchToIDFile. Переключение контекста между пользователями (например, переключение с пользователя-администратора на другого пользователя и обратно) в несколько раз снижает производительность. Кроме того, SECKFMSwitchToIDFile требует, чтобы существовал и был в актуальном состоянии ID-файл пользователя. Это означает, что Notes-приложение должно следить за пользовательскими ID-файлами и обнаруживать изменения, влияющие на ID-файлы (изменения Name и публичного ключа). Новые API могут обнаруживать эти изменения вместо вас и упрощают управление ID-файлами. Использование новых API системы защиты не обязательно, но поможет вам преодолеть описанные выше ограничения.

Кроме того, существовавшие прежде API PKCS12_ExportIDFileToFile и PKCS12_ImportFileToIDFile позволяют выполнять импорт и экспорт интернет-сертификатов и ключей в ID-файл. Имея интернет-сертификаты и частные ключи в ID-файле, можно прочитать S/MIME-шифрованное почтовое сообщение и передать почтовое сообщение, подписанное S/MIME-кодом. Хотя этот метод позволяет читать S/MIME-сообщения (если у вас есть соответствующий крипто-механизм), это может быть не удобным решением для вас, а также может использоваться для дешифровки лишь S/MIME-шифрованных сообщений. Новые API облегчают доступ/создание как Notes-шифрованных, так и S/MIME-шифрованных сообщений.


Новые API Notes/Domino

Более подробное и точное описание этих API приведено в "Справочнике по Lotus C API Notes/Domino 7.0" и "Руководстве пользователя". В данном разделе содержатся краткие описания API, которые будут рассмотрены в данной статье.

SECKFMOpen

Этот метод предоставляет описатель полномочий (credential handle) ID-файла, если вы передадите корректные имя ID-файла и пароль. Этот описатель полномочий затем может передаваться в другие функции в данном списке, так что переключение контекста между пользователями через SECKFMSwitchToIDFile становится не нужным. Шифрование/дешифрование невозможно без правильных полномочий.

SECKFMClose

Закрывает описатель SECKFMOpen по завершении вашей работы с ним.

SECAttachIdFileToDB

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

SECExtractIdFileFromDB

Эта функция отсоединяет ID-файл, присоединенный функцией SECAttachIdFileToDB. ID-файл должен быть отсоединен, для того чтобы передать в SECKFMOpen соответствующий ID-путь.

SECRefreshIdFile

Эта функция проверяет в каталоге для данного пользователя изменения Notes-сертификации, изменения Internet-сертификации и переименование пользователя. Вы передаете в этот метод ID-файл, пароль и сервер, на котором нужно проверить изменения. Если какое-либо изменение обнаруживается, ID-файл будет обновлен. Обычно, при обнаружении изменений вы должны повторно присоединить ID-файл при помощи SECAttachIdFileToDB. Вы должны всегда вызывать SECRefreshIdFile после извлечения ID, чтобы гарантировать его актуальность.

NSFNoteDecrpytExt2

Это расширение NSFNoteDecryptExt. Вы передаете в этот метод описатель полномочий KFM, для того чтобы можно было корректно дешифровать сообщение.

NSFNoteCopyAndEncryptExt2

Это расширение NSFNoteCopyAndEncrypt. Вы передаете в этот метод описатель полномочий KFM, для того чтобы можно было корректно зашифровать сообщение.


Использование новых API системы защиты

Прежде чем произойдет шифрование/дешифрование, должен быть доступен Notes ID с полномочиями для защищенного документа, чтобы могли быть использованы корректные полномочия. Если у вас есть пользовательский ID-файл и пароль, вы можете присоединить ID-файл к почтовому файлу, используя новую функцию SECAttachIdFileToDB. Например, ваше Notes-приложение может сохранять каждый пользовательский ID-файл в $MyId (или другое уникальное имя) документа профиля. Вообще говоря, существует бесчисленное множество интерфейсов, через которые ваше приложение может запросить и сохранить пользовательский ID и пароль. Ваше приложение решает, как предоставить нужный интерфейс способом, который приемлем для конечного пользователя и архитектуры вашего продукта.

Используя Domino Web Access в качестве примера, Notes ID присоединяется как профиль $shimmerid. Вы можете проверить, что документ $shimmerid существует, используя программу Notespeek, которая покажет вам список ID (см. рисунок 1).

Рисунок 1. Список ID Notespeek
Список ID Notespeek

Domino Web Access предоставляет хороший пример пользовательского интерфейса, позволяющий пользователям присоединять свои Notes ID-файлы. Как вы можете увидеть на закладке Security Preferences, показанной на рисунке 2, пользователи могут выбрать свой Notes ID-файл и предоставить пароль.

Рисунок 2. Закладка Security Preferences
Закладка Security Preferences

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

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

Использование присоединенного ID для чтения зашифрованных сообщений

Ваше приложение должно определить, зашифрован ли документ. Оно может сделать это при помощи Notes API-метода NSFNoteIsSignedOrSealed. Если ваше приложение определяет, что сообщение зашифровано, тогда оно может использовать новые API системы защиты. Одни из подходов мог бы состоять из следующих шагов:

  1. Отсоедините пользовательский ID-файл от почтового файла, используя метод SECExtractIdFileFromDB (пользователь должен иметь ID-файл в своем почтовом файле для этого действия; как это сделать, описано выше в данном разделе). Вы должны также иметь пароль пользователя ID-файла.
  2. Вызовите метод SECRefreshIdFile с отсоединенным ID-файлом. Это гарантирует отображение в ID-файле изменений Notes-сертификации, интернет-сертификации и переименования пользователя.
  3. Если SECRefreshIdFile обнаружил какие-либо изменения, повторно присоедините ID-файл к почтовому файлу, используя SECAttachIdFileToDB.
  4. Передавая отсоединенный ID-файл/пароль в качестве параметра, используйте SECKFMOpen для извлечения описателя ID-файла.
  5. Используйте описатель ID-файла в методе NSFNoteDecrpytExt2 для доступа к зашифрованному сообщению. Убедитесь, что содержимое остается защищенным после дешифровки, поскольку зашифрованные сообщения, обычно, содержат важные данные.
  6. Используйте SECKFMClose для закрытия описателя ID-файла.
  7. Закройте сообщение и удалите отсоединенный ID-файл из хранилища.

Использование присоединенного ID для создания зашифрованных сообщений

Если ваше приложение должно дешифровать сообщение, оно может воспользоваться новыми API системы защиты. Вот один из способов, которым можно это сделать:

  1. Отсоедините пользовательский ID-файл от почтового файла при помощи метода SECExtractIdFileFromDB (опять же, пользователь должен иметь ID-файл в своем почтовом файле, для того чтобы это сработало). Вы должны также иметь пароль пользователя для ID-файла.
  2. Выполните метод SECRefreshIdFile с отсоединенным ID-файлом. Это гарантирует отображение в ID-файле изменений Notes-сертификации, интернет-сертификации и переименования пользователя.
  3. Если SECRefreshIdFile обнаружил какие-либо изменения, повторно присоедините ID-файл к почтовому файлу, используя SECAttachIdFileToDB.
  4. Передавая отсоединенный ID=файл/пароль в качестве параметра, используйте SECKFMOpen для извлечения описателя ID-файла.
  5. Используйте описатель ID-файла в методе NSFNoteCopyAndEncryptExt2 для шифрования документов.
  6. Используйте SECKFMClose для закрытия описателя ID-файла.
  7. Закройте сообщение и удалите отсоединенный ID-файл из хранилища.

Другие концепции для администрирования Notes ID

Вероятно, вы захотите, чтобы ваше приложение было способно шифровать и/или дешифровать сообщения от различных пользователей. В этом случае может быть не удобно присоединять каждый ID-файл индивидуально. Ваше Notes-приложение может выполнить большую работу по присоединению нескольких ID-файлов для упрощения процесса.

Поскольку ваше Notes-приложение обращается ко всем ID-файлам и паролям, которые должны быть присоединены к пользовательским почтовым файлам для шифрования/дешифрования, оно может использовать метод SECAttachIdFileToDB для присоединения всех ID-файлов. Вы могли бы создать инструмент для присоединения всех ID в цикле. Ваша программа нуждалась бы в некоторого рода защищенном репозитории, содержащим пользовательские ID-файлы и пароли для чтения из этого репозитория. ID-файлы и пароли должны были бы храниться в защищенной и конфиденциальной форме.

Как предоставить пользователю возможность изменять их Notes ID пароль

В целях безопасности вы можете захотеть предоставить индивидуальным пользователям вашего приложения возможность изменить пароль Notes ID, используемый вашим приложением для создания/чтения зашифрованных сообщений. Одним из примеров того, когда они захотели бы изменить свои пароли, является компрометация паролей. Также ваше Notes-приложение может нуждаться в создании политик, гарантирующих изменения паролей Notes ID пользователями вашего приложения на регулярной основе.

На рисунке 3 показано диалоговое окно Change Internet Password в Domino Web Access. Оно позволяет пользователям изменять свои Notes ID пароли. Ваше приложение может использовать это диалоговое окно в качестве модели.

Рисунок 3. Диалоговое окно Change Internet Password
Диалоговое окно Change Internet Password

Вы можете захотеть предоставить интерфейс для сбора существующего пароля и нового пароля пользователя. Этот интерфейс мог бы затем обеспечить этими данными ваше приложение. Одним из способов сделать это может быть выполнение следующих действий:

  1. Отсоедините пользовательский ID-файл от почтового файла при помощи метода SECExtractIdFileFromDB.
  2. Выполните метод SECRefreshIdFile с отсоединенным ID-файлом. Это гарантирует отображение в ID-файле изменений Notes-сертификации, интернет-сертификации и переименования пользователя.
  3. Используя данные о новом пароле, выполните метод SECKFMChangePassword для изменения пароля.
  4. Повторно присоедините ID-файл к почтовому файлу, используя SECAttachIdFileToDB.
  5. Закройте сообщение и удалите отсоединенный ID-файл из хранилища.

Заключение

В этой статье мы познакомили вас с новыми API системы защиты, представленными в Notes/Domino 7. Мы также показали вам, как использовать эти API и предложили некоторые практические примеры приложений. Мы надеемся, что вы нашли эту статью полезной. Не стесняйтесь присылать предложения по другим связанным с системой защиты Notes/Domino темам, рассмотрение которых вы хотели бы увидеть в будущих статьях.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Lotus
ArticleID=166569
ArticleTitle=API защиты в Notes/Domino 7.0
publish-date=07262005