1) определяетесь с фрагментом который должен быть подписан и алгоритмами подписи. Фрагмент должен иметь атрибут типа xs:ID обычно это или просто Id или wsu:Id, если второе то не забыть объявление xmlns:wsu
Важно чтобы в документе не было других тегов с таким же значением атрибута Id.
Подписывать надо сначала самую дальную от корня ЭП и постепенно подниматься к корню (сначала ЭП-СП если нужна, потом ЭП-ОВ). Это важно потому что при проверке ЭП-ОВ, в тексте остается все содержимое ЭП-СП. Если наложить ЭП-СП после ЭП-ОВ, то ЭП-ОВ будет вычислена без присутствия ЭП-СП, а проверяться уже с присутствием ЭП-СП. Насчет того, поможет ли с этим трансформ enveloped-signature я не проверял, но скорее нет чем да. Поверх этого СМЭВ наложит еще и ЭП-СМЭВ.
2) заполняете шаблон Signature - SignedInfo в соответствии с алгоритмами CanonicalizationMethod (желательно эксклюзивная каноникализация вообще всегда, не только в СМЭВ, чтобы не зависеть от места вставки подписи) SignatureMethod (гост-2012 сейчас)
3) добавляете Reference c URI указывающим на подписываемый фрагмент, указываете алгоритм хэша DigestMethod (гост-2012 сейчас), трансформы - состав зависит от целевой системы, порядок трансформов важен (эксклюзивная каноникализация и смэвовский, если речь о смэв 3). Если есть enveloped-signature он идет в начало, а специфичный для системы как смэвовский в конец.
4) выбираете подписываемый фрагмент (с контекстом из документа, подробнее ниже) и применяете к нему по порядку трансформы из Reference (если трансформов было не указано, то может применяться каноникализация)
5) трансформированный в 4 фрагмент идет на вычисление хэша (алгоритм хэша по Reference).
Создается "пустой" экземпляр криптопровайдера без ключей и на нем открывается хэш-объект, добавляются данные, вычисляется и запрашивается значение хэша, хэш-объект закрывается.
6) полученное значение при необходимости переворачивается (о том ниже), потом кодируется в Base64 и записывается в Reference - DigestValue.
7) шаги 3-6 повторяются если несколько подписываемых одной подписью фрагментов (в смэв только один, а вот если нужна подпись xades-bes или xades-t, то данные xades добавляются как еще один Reference, но это немного другая история).
8) после того как все Reference добавлены все изменения SignedInfo блокируются, выбирается SignedInfo (с контекстом из документа), применяется CanonicalizationMethod (иные трансформы не применяются)
9) от каноничного SignedInfo считается хэш по алгоритму согласованному с SignatureMethod (для алгоритма подписи гост-2012 возможен только хэш гост-2012, хэш также указан как часть в идентификаторе алгоритма подписи)
Если брать голое CryptoApi, то есть разница между вызовом подсчета хэша в шаге 5 и 7, связанная с тем нужно подписывать хэш или нет.
Более точно про хэш: создается экземпляр криптопровайдера с конкретным контейнером закрытого ключа (при этом запрашивается пин-код). На этом экземпляре открывается хэш-объект, добавляются данные, вычисляется (значение хэша запрашивать не обязательно), хэш-объект НЕ закрывается.
10) хэш-объект подписывается закрытым ключом (значение подписи возвращается сразу без дополнительного запроса), хэш закрывается.
11) полученное значение при необходимости переворачивается (о том ниже), потом кодируется в Base64 и записывается в SignatureValue.
12) к Signature добавляется KeyInfo (информация о сертификате) и при необходимости обертка wsse:Security - это тоже немного другая история.
13) если Signature формировалась отдельно, вставляется в документ.

1) документ сканируется на наличие подписей (не уверен ФЛК до проверки подписей или после). Проверка начинается с ближней от корня подписи. То есть сначала если есть ЭП-СМЭВ, потом ЭП-ОВ, потом если есть ЭП-СП.
2) c SignedInfo делаются те же действия что на шаге 8 подписания.
3) хэш от каноничного SignedInfo
Создается "пустой" экземпляр криптопровайдера без ключей и на нем открывается хэш-объект, добавляются данные, вычисляется, хэш-объект НЕ закрывается (значение хэша запрашивать не обязательно).
4) из подписи выделяется сертификат, декодируется из base64, из сертификата выделяется структура с описанием открытого ключа (для этого можно импортировать сертификат и получить контекст сертификата в котором соответствующее место будет вычислено автоматически, но можно и просто вырезать соответствующую часть сертификата если известно место), структура с открытым ключом импортируется в "пустой" экземпляр криптопровайдера (может быть тот же что в шаге 2 или новый), получается дескриптор открытого ключа;
5) из подписи выделяется SignatureValue, декодируется из base64. Если перед записью был переворот значения, то после декодирования нужно опять же перевернуть значение.
6) полученный в шагах 3-5 данные (хэш-объект от каноничного SignedInfo, дескриптор открытого ключа, декодированное значение подписи) передаются в функцию проверки, откуда только получается логическое значение верна математически подпись или нет. Если любые из данных искажены - изменилось SignedInfo, неправильно было каноникализировано при подписи, нет тот сертификат или неправильное значение подписи, то ответ будет что подпись неверна и проверка подписи прерывается.
7) Если же проверка SignatureValue успешна, то для каждого Reference выполняются шаги 4-5 подписания и полученный хэш сравнивается с декодированным значением DigestValue. Если перед записью DigestValue был переворот значения, то после декодирования нужно опять же перевернуть значение. Если значения не сошлись проверка прерывается.
Для Reference с особым типом (при подписи xades, например) запускается отдельные проверки - это уже другая история.
Тонкий момент в том, что xades это расширение формата xmldsig и в зависимости от выбранного формата проверки ошибка в xades может быть не выявлена проверкой xmldsig, что ведет к тому что разные программы дают разный результат проверки.
8) Если на шаге 7 ошибок не выявлено подпись считается математически корректной. На этом моменте тестовая страничка выдаст что ЭП верна, но СМЭВ продолжит проверять сертификат.
9) Для каждого сертификата получается вышестоящий и проверяется подпись в самом сертификате открытым ключом вышестоящего сертификата. Для корневого сертификата открытый ключ берется в нем самом. Далее проверяется что корневой сертификат есть в списке доверенных, и нет информации об отзыве любого сертификата в цепочке. Если все верно, то ЭП признается верной.