Цифровые подписи

  • Статья

Руководство по применению цифровых подписей в рамках стандарта Common Criteria

Джек Дэвис

Переход от бумажных документов с подписями от руки к электронным файлам с цифровыми подписями идет весьма быстро. Чтобы соответствовать требованиям пользователей и сертификации, электронные документы с цифровыми подписями должны обеспечивать тот же уровень безопасности, что и бумажные документы, подписываемые от руки. В этой статье рассказывается, как разработчик ПО может добиться этой цели: проектировать приложения со встроенной функциональностью цифрового подписания, отвечающей требованиям стандарта защиты ISO/IEC 15408 Common Criteria.

В области документов и файлов данных цифровые подписи обеспечивают две ключевые функции:

  • идентифицируют автора (подписывающего) документа или содержимого файла;
  • удостоверяют, что подписанная информация не изменялась после применения цифровой подписи.

Помимо базового принципа «что видишь, то и подписываешь» («What You See Is What You Sign», WYSIWYS), вы и ваши проектировщики UI при создании приложений с поддержкой цифровых подписей должны учитывать несколько дополнительных соображений, касающихся безопасности и пользователей. Вы также должны понимать проблемы защиты, которые могут повлиять на соответствие ваших продуктов требованиям сертификации. Сертификация, например по стандарту ISO/IEC 15408 Common Criteria, дает организациям и пользователям надежный способ идентификации продуктов, протестированных на соответствие стандартов удобства и безопасности в применении. Независимая сертификация безопасности все чаще становится обязательным условием заказчиков.

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

Сертификация по стандарту ISO/IEC 15408 Common Criteria

Common Criteria, поддерживаемый International Organization for Standardization (ISO) и International Electrotechnical Commission (IEC), — это набор методологий для оценки и сертификации средств защиты ИТ-продуктов. Принципы безопасности Common Criteria опубликованы в стандартах ISO/IEC 15408 и 18045.

На момент написания этой статьи стандарт Common Criteria одобрен и принят в 26 странах. Список участников Common Criteria см. по ссылке commoncriteriaportal.org/members.html.

Office Open XML и Open Packaging Conventions

В 2008 году ISO и IEC утвердили и приняли Office Open XML (OOXML) как открытый международный стандарт. Open Packaging Conventions (OPC) — часть OOXML — описывает стандартную в отрасли технологию файлов-контейнеров. OPC на основе комбинации ZIP и XML позволяет приложениям определять файловые форматы — открытые и легко доступные. OPC также определяет функциональность для поддержки цифровых подписей, свойств метаданных и взаимосвязей в контенте. Доступ к данным приложения и элементам OPC осуществляется через общий API.

Microsoft Word (.docx), Excel (.xlsx), PowerPoint (.pptx) и XML Paper Specification (.xps) — примеры файловых форматов на основе OPC, и в каждом из них применяется собственная уникальная организация контента (схема), связанная со спецификой конкретного приложения. Каждый OPC-формат файлов также позволяет определять свою политику подписания с помощью цифровых подписей. Эта политика в процессе подписания или проверки указывает, какие части содержимого подписывать обязательно, какие — не обязательно, а какие — и вовсе не следует подписывать.

Я также подробнее расскажу о том, как проверять и отображать сведения о цифровой подписи, хранящиеся в электронных документах с цифровыми подписями. Функциональность, связанную с цифровыми подписями, предоставляет компонент OPC стандартов ISO/IEC 29500 и ECMA 376 Office Open XML. Учтите, что правила подписания для конкретных файловых форматов на основе OPC могут применять лишь подмножество вариантов подписания, изложенных в этой статье.

Цифровые подписи

Файловые форматы OPC вроде описанных в OOXML используют сертификаты X.509 и технологии XML Digital Signature (W3C, 2008 г.), обеспечивая два элемента безопасности:

  • неотрекаемость (non-repudiation) надежно идентифицирует индивидуальное лицо или группу, подписывающую документ;
  • проверка содержимого (content validation) гарантирует, что весь подписанный контент присутствует и не был ни в малейшей степени изменен после подписания.

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

Некоторые иллюстрации в этой статье — примеры уведомлений для пользователей. Сообщают они об успехе или неудаче проверки подписи или обращают внимание на специальные функции, о которых должен знать пользователь, уведомления написаны четким языком, и вы должны взять их за образец. Ваше приложение определяет, когда и где пользователь увидит эти сообщения о состоянии цифровой подписи. Проверка цифровых подписей иногда планируется так, чтобы она автоматически выполнялась при каждом открытии подписанного документа. В этом случае сообщение должно появляться, когда пользователь открывает документ. Если пользователю нужно вручную выполнить проверку цифровой подписи (например, выбрав команду в меню), вы могли бы сообщать о состоянии цифровой подписи во всплывающем диалоговом окне. Настройка приложения на то, чтобы сообщать об успехе или неудаче при проверке целостности цифровой подписи и подписанного содержимого, — это лишь первый шаг в создании программы, поддерживающей защиту на основе цифровых подписей.

Категории подписей

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

В простейшей форме подписания — его называют полным (comprehensive signing) — пользователь применяет свою подпись ко всему содержимому в рамках одного документа. Эта подпись и подписанный контент впоследствии проверяются, а затем о них сообщается, действительны ли они. На рис. 1 приведен пример такого рода сообщения.

Рис. 1. Пример сообщения при использовании полного подписания

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

  • неподписанном контенте;
  • подписанных группах контента;
  • контенте со ссылками на внешние документы;
  • динамическом контенте.

Полное подписание

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

Как уже упоминалось, самый простой и «лобовой» случай подписания цифрового документа — полное подписание (comprehensive signing). Чтобы подпись можно было отнести к такому типу, все содержимое, связанное с файлом документа, должно отвечать четырем критериям:

  • все элементы контента расположены в одном пакете документа;
  • все элементы контента статические;
  • нет ссылок на внешний контент;
  • все элементы контента в пакете документа подписаны.

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

На рис. 2 подпись Signature 1 охватывает части документа r, s и t. Впоследствии при проверке будет удостоверено, что Signature 1 по-прежнему действительна, а каждая из подписанных ею частей (r, s и t) не менялась после подписания.


Рис. 2. Контент, подписанный одной подписью

Рис. 3 иллюстрирует один из вариантов подписания, в котором к документу применяются две или больше подписей. Несколько подписей обычно встречается в цикле рецензирования и утверждения, где каждый участник цикла должен подтвердить свое одобрение документа после его рецензирования. В этом случае каждую подпись можно проверять независимо наряду с соответствующими подписанными частями документа.


Рис. 3. Контент, подписанный несколькими подписями

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

  • метод PackageDigitalSignatureManager.VerifySignatures позволяет проверить, действительны ли подписи и не изменялись ли подписанные части внутри пакета;
  • свойство PackageDigitalSignature.Signer возвращает копию сертификата X.509, который идентифицирует автора подписи;

Неподписанный контент

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

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

Доверенные связи подписи должны быть ясны всем пользователям. Они должны знать о любом неподписанном контенте, включенном в любой пакет, и располагать средствами, позволяющими четко отличать его от доверяемого подписанного контента. На рис. 4 показан образец сообщения, которое должны получать пользователи при обнаружении в корректно подписанном документе неподписанного контента.

Рис. 4. Образец сообщения о неподписанном контенте

На рис. 5 части документа m и n подписаны, и их можно проверить с помощью подписи Signature 1. Тот же пакет документа содержит неподписанные части x и y, которые нельзя проверить. Части x и y независимы и не связаны (даже неявно) с подписью Signature 1.


Рис. 5. Подписанный документ, включающий неподписанные части

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

  • свойство PackageDigitalSignature.Signer возвращает копию сертификата X.509, который идентифицирует автора подписи;
  • метод Package.GetParts возвращает набор всех частей, содержащихся в пакете;
  • свойство PackageDigitalSignature.SignedParts возвращает набор всех частей, подписанных данной подписью.

Следующий псевдокод определяет, есть ли в пакете документа какие-либо неподписанные части:

PackageDigitalSignatureManager dsm = new PackageDigitalSignatureManager(package);
PackagePartCollection partCollection = Package.GetParts();
foreach (PackagePart part in partCollection)
    foreach (PackageDigitalSignature signature in dsm.Signatures)
    {
        // Search if "part" is included in signature.SignedParts.
        // If "part" is included in signature.SignedParts
        //     then it is a signed part
        //     else it is an unsigned part
    }

Подписанные группы контента

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

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

Рис. 6. Образец сообщения при наличии подписанных групп контента

На рис. 7 части документа r, s и t подписываются и проверяются подписью Signature 1, а части документа x, y и z — подписью Signature 2. Две подписи и связанные с ними группы контента независимы друг от друга, хотя все они содержатся в одном документе.


Рис. 7. Две подписанные группы

Рис. 8 иллюстрирует ситуацию, в которой одна или несколько частей документа совместно подписаны двумя или более подписями. Хотя Signature 1 и Signature 2 совместно подписывают один или более общих элементов (группа C), подпись Signature 1 для группы A и подпись 2 для группы B остаются независимыми и ничем не связанными друг с другом. В описании подписей для пользователей вы обязательно должны явно и четко объяснить все эти сопоставления подписей.


Рис. 8. Независимо и совместно подписанные группы

Следующие свойства и псевдокод идентифицируют пакеты, содержащие несколько подписанных групп контента:

Следующий псевдокод создает список подписанных групп контента в пакете:

PackageDigitalSignatureManager dsm = 
   new PackageDigitalSignatureManager(package);
foreach (PackageDigitalSignature signature in dsm.Signatures)
{
    // Add to list(signature.SignaturePart, signature.Signer);
}
// Upon completion the list will contain one entry for each signature
// along with the X.509 certificate that identifies the signer.
// If the list contains more than one entry and different signers,
// the package contains multiple signed content groups.

Защита при наличии нескольких подписанных групп контента

Наличие нескольких подписанных групп контента усложняет политику подписания файла, так как они увеличивают вероятность того, что кто-то добавит в документ содержимое с фальшивой подписью с намерением создать неправильную ассоциацию с существующими подписью и контентом. Чтобы обезопасить свое приложение от этой угрозы, вы можете требовать от пользователя подписания части signature-origin-relationships пакета. (Эта часть является особым файлом в пакете с именем \package\services\digital-signatures\_rels\origin.psdor.rels.) Если подписываются и контент, и часть signature-origin-relationships, любая подпись, добавленная позднее, приведет к модификации части signature-origin-relationships, а значит, проверка исходной подписи закончится неудачей и пакет будет считаться недействительным.

Внешний контент

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

Контент, доступный через внешние ссылки, может быть изменен в любой момент. В идеале, подписываемый контент не должен содержать никаких ссылок на материалы вне пакета документа. У пользователей должна быть возможность четко распознавать ситуации, где приходится подписывать и проверять контент, включающий ссылки на внешние материалы. На рис. 9 приведен образец сообщения, указывающий на наличие в документе ссылок на внешний контент.

Рис. 9. Образец сообщения при наличии ссылок на внешний контент

При проверке подписанного контента, который включает ссылки на внешние материалы, придерживайтесь следующих правил.

  • Оповещайте пользователей о наличии таких ссылок. В уведомлении поясняйте, что внешние материалы не подписаны и не связаны ни с какой подписью в данном документе.
  • Предоставляйте пользователям средства четкого различения подписанного статического контента и неподписанного внешнего материала. Например, когда пользователи проверяют и просматривают подписанный контент, следует показывать только внутренние ссылки на другой подписанный контент — ссылки на внешний контент скрывайте.

На рис. 10 части документа r, s и t подписаны, и их можно проверить с помощью Signature 1. Однако часть документа s содержит внутреннюю ссылку на часть t и ссылки на внешний неподписанный контент x и y. Проверяя и описывая информацию о подписях для пользователей, приложение должно явно и четко уведомлять их о том, что ссылки x и y указывают на неподписанный контент, не связанный с подписью Signature 1 и не имеющий никакого отношения к другим действительным элементам документа (частям r, s и t).


Рис. 10. Внешний контент

Идентификация элементов, ссылающихся на внешний контент, зависит от схемы конкретного OPC-формата файла. В сопутствующих материалах вы найдете методы, свойства и псевдокод, позволяющие идентифицировать внешний контент в файловых форматах Microsoft Office для Word (.docx), Excel (.xlsx) и PowerPoint (.pptx).

Динамический контент

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

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

Динамический контент, создаваемый в результате выполнения пользовательских макросов, может применяться с злонамеренными целями, и представляет угрозу безопасности. Выполняемые операции добавляют сложность, которая затрудняет четкое понимание пользователями рисков, связанных с динамическим контентом. Чтобы сохранить действие принципа WYSIWYS, документы, подлежащие подписанию, не должны включать динамический контент и вместо него использовать только статическое содержимое.

Ситуации, в которых приходится подписывать и проверять документы с динамическим контентом, должны ясно и четко представляться пользователям. Если документ с динамическим контентом все же подлежит подписанию, придерживайтесь следующих правил:

  • Оповещайте пользователей о наличии динамического контента. В уведомлении поясняйте, что динамический контент не подписан и что его нельзя связать ни с каким уровнем доверия к подписи.
  • Предоставляйте пользователям средства четкого различения подписанного статического контента и неподписанного динамического контента. Например, когда пользователи проверяют и просматривают подписанный контент, следует скрывать динамический контент; подписывающий должен видеть только изначально показываемый статический контент.

На рис. 11 приведен образец сообщения, предупреждающего пользователя о динамически создаваемом контенте.

Рис. 11. Образец сообщения о наличии динамического контента

На рис. 12 части документа r и s подписаны и могут быть проверены подписью Signature 1. Однако в пакете документа также содержится динамический контент — часть z, которую нельзя подписать или проверить. Часть z независима и не связана (даже неявным образом) с подписью Signature 1.


Рис. 12. Динамический контент

Идентификация элементов, содержащих динамический контент, зависит от схемы конкретного OPC-формата файла. В сопутствующих материалах в Интернете вы найдете методы, свойства и псевдокод, позволяющие идентифицировать динамический контент в файловых форматах Microsoft Office для Word (.docx), Excel (.xlsx) и PowerPoint (.pptx).

Поддержание транспарентности

Снова повторю: создавая приложения с поддержкой цифровых подписей, нужно обеспечивать тот же уровень безопасности и транспарентности, что и в бумажных документах, подписываемых от руки. Кроме понимания базовых операций проверки сертификатов подписей (X.509) и подписанного контента (криптографических хешей), вы и ваши проектировщики UI должны продумать поведение приложения в любых ситуациях, которые могут быть непонятны пользователям на интуитивном уровне.

Если суммировать все сказанное, потенциальные проблемы могут возникать из-за:

  • наличия и идентификации неподписанного контента;
  • сопоставлений между авторами подписей нескольких групп контента;
  • наличия и идентификации внешнего неподписанного материала;
  • наличия и идентификации неподписанного динамического контента.

Если вы не исключаете такие типы контента в проекте своего приложения, вы должны предоставлять пользователям четкую информацию. Снова повторю: предоставление точной и четкой информации пользователям является фундаментальным требованием для сертификации защиты по стандарту ISO/IEC 15408 Common Criteria.

При переходе на использование электронных документов пользователи, для которых безопасность очень важна, все более будут полагаться на независимую сертификацию, например в соответствии со стандартом ISO/IEC 15408 Common Criteria. Чтобы занять прочные позиции на рынке, приложение должно отвечать потребностям пользователей и соответствовать стандартам сертификации безопасности.

Дополнительные сведения и ссылки на стандарты см. в сопутствующих материалах в Интернете. Там же дан обзор по идентификации динамического и внешнего контента в документах Microsoft Office.

Jack Davis is program manager for the Windows OPC “Packaging” team. Davis is a prior contributor to MSDN Magazine (“OPC: A New Standard for Packaging Your Data,” August 2007) and blogs on the Microsoft Packaging team’s Web site at blogs.msdn.com/opc. He can be reached at jack.davis@microsoft.com.

Web Content for “Application Guidelines on

Digital Signature Practices for Common Criteria Security”

The following links provide information you’ll need to ensure that your applications follow accepted practices for using digital signatures.

Web addresses can change, so you might be unable to connect to the Web sites mentioned here.

Identifying Dynamic and Externally Referenced Content in Office Documents

Identifying elements of dynamic content or externally referenced content is dependent on the schema of the specific OPC file format. This section provides an overview of how to identify dynamic and externally referenced content in Office Open XML (OOXML) file formats for Word (.docx), Excel (.xlsx) and PowerPoint (.pptx). This overview is not all-inclusive – for additional details, refer to ISO/IEC 29500-3 Part 3: Markup Compatibility and Extensibility of the OOXML file format standard.

Office Document Structure

OOXML file formats for Word, Excel and PowerPoint documents employ a common structure for storing content.

  • /[Content_Types].xml file
  • /_rels/ folder
  • /docProps/ folder
  • /documentType/ folder, where /documentType/ is:
    • /word/ for Word documents (.docx)
    • /xl/ for Excel documents (.xlsx)
    • /ppt/ for PowerPoint documents (.pptx)

The [Content-Types].xml part contains the Multipurpose Internet Mail Extension (MIME) types for all parts contained in the package. Two element types can be defined in the content type markup:

  • Default Extension elements define default associations between a part (filename) extension and a specified MIME content type. For example,
<Default Extension="png" ContentType="image/png" />
  • Override PartName elements define associations for specific parts and a specified MIME content type. For example,
<Override PartName="/word/footnotes.xml"
           ContentType="application/vnd.openxmlformats-
                       officedocument.wordprocessingml.footnotes+xml" />

You can use the ContentType attribute for the elements contained in the [Content-Types].xml part to identify the types of items stored in the package ( e.g., Visual Basic project files used in macros).

For additional information on OOXML file format markup, see ISO/IEC 29500 Part 1: Fundamentals and Markup Language Reference.

Word Documents

Fields

Word documents can include fields. Fields can define various objects, such as time, date, document properties, links, references to external content, form fields and so on. Fields used in this manner can provide dynamic content. There are two types of fields: simple and complex.  

The following pseudo-code (p-code) shows how to identify simple-field elements.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘<w:fldSimple *> * </w:fldSimple>’)
    then
       a simple-field exists

Complex fields are described in multiples lines that contain a starting statement, a field description and an ending statement. The following p-code shows how to identify complex-field elements.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();   // Returns a Stream containing the part content
    if str contains (‘<w:fldChar fldCharType="begin" * />’)
    then
       a complex-field exists

Macros

Macros are another mechanism that can provide dynamic content. Macros are stored in Word documents as Visual Basic files. In Word documents that use macros, the document /[Content_Types].xml file contains a MIME content type reference for a Visual Basic project. The following p-code shows how to identify the use of macros.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘*vbaProject’)
    then
       a macro exists

External References

Word documents can define external references through the use of hyperlinks, subdocuments, OLE objects or mail-merge elements. The following p-code outlines one way to identify if a document uses external references.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘href’ or ‘Hyperlink’ or ‘External’)
    then
       an external reference exists

Excel Documents

Calculated Fields

Within an Excel document, dynamic content is stored in calculated fields whose value is calculated from a function. The following p-code shows how to identify the use of calculated cells in an Excel document.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘<f *> * </f>’)
    then
       a calculated field exists

Date and Time

Date and time information, such as in headers and footers, can be defined to be automatically updated (such as when printing). Dynamic date and time information is defined in the sheet description file \xl\worksheets\sheetX.xml, where X represents the sheet number. The sheet description file can contain header and the footer elements (headerFooter) that define the associated content. Content values &C, &D and &T serve as placeholders for dynamic date and time values. Within the XML markup, &C stands for Current, &D stands for Date and &T stands for Time. &C will always appear before &D and &T, and it’s possible to concatenate both of them building strings like &C&D&T or &C&T&D.

Macros

Similar to Word documents, macros are stored in Excel documents as Visual Basic files. For documents that use macros, the /[Content_Types].xml file will contain a MIME content type reference for a Visual Basic project. The p-code to detect the use of macros in Excel is similar to that for Word. You can use the p-code in the “Macros” part of the preceding “Word Documents” section to detect the use of macros in Excel as well.

External References

External references in Excel are implemented in the same way as in Word. Refer to the “External References” part of the preceding “Word Documents” section for further information on identifying external references in Excel.

Data from Databases and External Data Sources

Excel additionally allows documents to get data dynamically from databases and other external data sources. External data sources are referenced through a connection definition to the external source. Connection definitions are specified in a /xl/connections.xml part that is stored in the package. Here are some possible data source connection types:

  • ODBC-based source
  • DAO-based source
  • File-based source
  • Web query
  • OLE DB-based source
  • Text-based source
  • ADO record set
  • Data set provider (DSP)

For additional information about data sources, see ISO/IEC 29500-1 Fundamentals and Markup Language Reference, section 12.3.4 Connections Part. The following p-code shows how to identify external data connections in an Excel document.

Package pkg = Package.open(filepath);
PackagePart connPart= pkg.GetPart("/xl/connections.xml");
if connPart is not null   // file "/xl/connections.xml" exists
then
   an external data source exists

Volatile Data

Volatile data is an additional way for Excel to connect to an external data source. Volatile dependencies operate by means of a data cache supported through real -time data (RTD). An RTD connection uses a COM object installed on the local machine to provide the desired data to the Excel document. For additional information about volatile data, see ISO/IEC 29500-1 Fundamentals and Markup Language Reference, section 18.15 Volatile Dependencies. The following p-code shows how to identify RTD connections in an Excel document.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘<volTypes *>’)
    then
       volatile data exists

PowerPoint Documents

Date and Time

Slides within a PowerPoint presentation can also contain dynamic date and time elements. Dynamic date and time information can be defined in each slide’s description file \ppt\slides\slideX.xml, where X is the slide number. Slides that contain dynamic date and time content have a date element with its type attribute set to the value datetime. The following p-code shows how to identify the presence of dynamic date and time elements in a PowerPoint document.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘datetime’)
    then
       a date-time element exists

Macros

Similar to Word and Excel documents, macros are stored in PowerPoint documents as Visual Basic files. For documents that use macros, the /[Content_Types].xml file will contain a MIME content type reference for a Visual Basic project. The p-code to detect the use of macros in PowerPoint is the same as that for Word and Excel documents.

External  References

External references in PowerPoint are implemented as they are in Word and Excel.