xml

James Clark invented the name Extensible Markup Language and its abbreviation XML. He has been quoted as saying, "XML isn't going to win any prizes for technical elegance. But it was just simple enough that it could get broad acceptance, and it has just enough Standard Generalized Markup Language (SGML) stuff in it that the SGML community felt they could embrace it." (SGML is a standard indicating how to specify a document language or tag set.)


The XML Recommendation defines a methodology for tag creation. It specifies neither tag semantics nor a specific tag set. That is, XML specifies structure, not meaning. You can define an infinite number of markup languages based on the XML Recommendation standards.


Once defined, tags are mixed with character data to form an "XML document." An XML document can take numerous forms. For example, it can be a logical structure within a computer program or an external file in the traditional sense. Likewise, an XML document can be sent as a data stream, reported as a database result set, or dynamically generated by one application and sent to another.

 XML is case sensitive.

Elements and tags

Element;
<Today> Breaking news </Today>

Tag
<Today>

Also closed tag:
<Today/>

Atribute
An attribute is a property of an element.
The attribute includes both the name and the value.
<Today answer="42">Some info</Today>

Well-Formed 

•  Every start-tag must have a matching end-tag, or be a self-closing tag.
•  Tags can’t overlap; elements must be properly nested.
•  XML documents can have only one root element.
•  Element names must obey XML naming conventions.
•  XML is case sensitive.
•  XML will keep whitespace in your PCDATA.

Well-formedness is the minimum requirement necessary for an XML document. It includes various syntactic constraints, such as every start-tag must have a matching end-tag and the document must have exactly one root element. If a document is not well formed, it is not an XML document. Parsers that encounter a malformed document are required to report the error and stop parsing.

XML Declaration
The following are all legal XML declarations.

<?xml version="1.0"?>
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<?xml version="1.0" standalone="yes"?>

Each XML declaration has up to three attributes.

• version*: the version of XML in use. Currently this always has the value 1.0, though there may be an XML 1.1 in the future. 
• encoding (optional): the character set in which the document is written.
• standalone (optional): whether or not the external DTD subset makes important contributions to the document's infoset. No is the default.
• yes specifies that this document exists entirely on its own, without depending on any other files.
• no indicates that the document may depend on an external DTD (DTDs are covered in Chapter 4).

System Identifier

<? Some instruction ?>

DTD - Document Type Definitions

<!DOCTYPE name [
<!ELEMENT name (first, middle, last)>
<!ELEMENT first (#PCDATA)>
<!ELEMENT middle (#PCDATA)>
<!ELEMENT last (#PCDATA)>
]>

CDATA

Everything starting after the <![CDATA[ and ending at the ]]> is ignored by the parser.

XMLNamespaces

The key is the xmlns:ppp attribute (xmlns stands for XML NameSpace).

We can declare more than one namespace for an element, but only one can be the default.

Immediately following the XML header is the Document Type Declaration,
<!DOCTYPE name [

Built-In Entities

&amp;—the & character

&lt;—the < character

&gt;—the > character

&apos;—the ' character

&quot;—the " character

XML Schemas

W3C XML Sc allow you to describe the structure for an XML document. 

XML Schema divides data types into two broad categories: simple and complex.

Examples:
<schema xmlns="http://www.w3.org/2001/XMLSchema">
or
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
or
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

Definitions:

Markup
The term  has its origins in the publishing industry. In traditional publishing, markup happens after the writing is complete but before the book goes to typesetting. An editor annotates the text with handwritten instructions for the typesetter. These instructions, which specify the layout, are known as markup. Many contemporary word processing programs insert electronic markup automatically as the user creates the text.

XML 

Is an open-specification, platform-independent, extensible, and increasingly successful profile of the Standard Generalized Markup Language (SGML) [ISO 8879].

Well-Formed Documents"Well formed" has an exact meaning in XML. A well-formed document adheres to the syntax rules specified by the XML 1.0 Recommendation. . If the document is not well-formed and an error appears in the XML syntax, the XML processor stops and reports the presence of a fatal error.

DTD
Document Type Definitions (DTDs) are important in data exchange. Parties exchanging data must agree on a format, and a DTD allows the specification of that format.

The DTD defines the grammar and vocabulary of a markup language, specifying what is and what is not allowed to appear in a document—for example, which tags can appear in the document and how they must nest within one another.

This grammar is known as a Document Type Definition. A DTD defines the allowable building blocks of an XML document; that is, it defines the document structure with a list of permissible elements, attributes, nestings, and so on.

<?xml version="1.0"?><!DOCTYPE memo SYSTEM "memo.dtd">

The term "PCDATA," which stands for "Parsed Character DATA,"

CDATA

CDATA is text that will notbe analyzed by a parser, except to look for the magic CDATA termination string

<![CDATA[<greeting>Hello, world!</greeting>]]>

Namespaces
The intent of XML namespaces is to eliminate naming conflicts in XML documents that contain element types and attributes from multiple XML languages.

<?xml version="1.0"?><name xmlns:family='http://mypage.com/classification'>

• The prefix "xmlns" is used only for namespace bindings and is not itself bound to any namespace name.

The Extensible Stylesheet Language (XSL)

W3C Recommendation [XSL] defines the XSL language for expressing stylesheets. XSL builds on the prior work on Cascading Style Sheets Level 1 [CSS1] and Level 2 [CSS2] and the Document Style Semantics and Specification Language [ISO 10179].

XSL was developed to give designers greater control over needed features during pagination of documents and to provide an equivalent "frame"-based structure for browsing on the Web. It also incorporates the use of the XLink language [Xlink] to insert elements into XML documents that create and describe links between resources.

XML Schema 
A schema is a model for describing the structure of information.
XML Schema is a way of describing the allowable syntax of XML

xmlns:xs="htp://www.w3.org/2001/XMLSchema"

An XML processor
Is more commonly called a parser.

PCDATA
Parsed Character DATA,

whitespace
Space character, new lines (what you get when you hit the Enter key), and tabs.

XML elements are treated just as for the HTML <PRE> tag.

 “readability” whitespace is called extraneous whitespace, which whitespace is not actually part of an element’s PCDATA,

A URI (Uniform Resource Identifier) 

• URL (Uniform Resource Locator)
• URN (Uniform Resource Name)
• They exist to provide a persistent, location example: urn:foo:a123,456

Resources:

XML formater without validation - http://www.webtoolkitonline.com/xml-formatter.html

Scrum story points

Story points:

1 story point = 30 min
2 story point = 1 h

16 story point = 8 h

16 story point = 8 h = one day
48 story point = 8 h for 3 day
80 story point = 8 h for 5 days

Python libraries libxml2 and pyXMLSec for Digital Signature

Here is one ancient library, so yes, let's work with this libraries. Asking why, well.
Business, business, business, numbers.

libxml2

>>> doc = libxml2.parseDoc(xml_file) # Parsing file
>>> doc = libxml2.parseFile(xml_file)  # Parsing html

Node itteration
All nodes:
>>> ctxt = doc.xpathNewContext() 
>>> ctxt.xpathEval('//*')
[<xmlNode (Envelope) object at 0x7f55b8a329e0>, ...]

>>> for node in ctxt.xpathEval('//*'): print(node.name)
Envelope
Header
Body
deliverSecure

...

def serialize(self, encoding=None, format=0)
>>> xml = doc.serialize()

Creating nodes

>>> print(libxml2.newNode("Security"))
<Security/>

findChild(parent, name, ns=None)

Searches a direct child of the parent node having given name and namespace

<Sender>

<Id>42</Id>

<Name>Really good name</Name>

</Sender>

Creating namespace:
>>> nswsse = sec.newNs('http://test.xsd', 'wsse')

>>> print(nswsse)

 xmlns:wsse="http://test.xsd"

>>> sec.setNs(nswsse)

>>> print(sec)

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/>

Adding attribute:

>>> sec.setProp("id", "900")

<xmlAttr (id) object at 0x7f30b8cc3638>

>>> print(sec)

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" id="900"/>

pyXMLSec

createTree
Creates a new XML tree with one root node rootNodeName.


>>> tets = xmlsec.createTree("test", "aa")

>>> print(tets)

<?xml version="1.0"?>
<test xmlns="aa"/>

findNode(parent, name, ns=None)

Searches all children of the parent node having given name and namespace href.

>>> find_node = xmlsec.findChild(doc, "Name")

>>> find_node.get_content()

'Really good name'

Information about element:

>>> xml_doc.getRootElement()

<xmlNode (Envelope) object at 0x7ffa545bfab8>

>>> xml_doc.getRootElement().nodePath()

'/soapenv:Envelope'

>>> xml_doc.nodePath()

'/'

>>> xml_doc.get_type()

'document_xml' or 'element'

>>> sign_node.get_name()
'Signature'

Variables:

>>> xmlsec.DSigNs

'http://www.w3.org/2000/09/xmldsig#'

Creating signature:

>>> signNode = xmlsec.TmplSignature(xml_doc, xmlsec.transformExclC14NId(), xmlsec.transformRsaSha1Id(), None)

>>> signNode.__str__()

'<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">\n<SignedInfo>\n<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>\n<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>\n</SignedInfo>\n<SignatureValue/>\n</Signature>'

>>> xmlsec.NodeSignature

'Signature'

Add reference:

>>> ref_node = signNode.addReference(xmlsec.transformSha1Id(), id=None, uri="", type=None)
>>> print(ref_node)
<Reference URI="">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue/>
</Reference>

Finding elements:

>>> xmlsec.findNode(xml_doc.getRootElement(), "Header", "http://website.com/schema/Method" )

<xmlNode (Header) object at 0x7f4e9804f710>

keyDataAesId()

The AES key data id.

keyDataX509Id()
The X509 key data id.

keyDataXmlWrite(id, key, node, keyInfoCtx)
Writes the key data of klass id from key to an XML node.

keyInfoNodeRead(keyInfoNode, key, keyInfoCtx)
Parses the <dsig:KeyInfo/> element keyInfoNode, extracts the key data and
stores into key.

keyInfoNodeWrite(keyInfoNode, key, keyInfoCtx)
Writes the key into the <dsig:KeyInfo/> element template keyInfoNode.

Resources:

libxml2

libxml2 tutorial - https://www.xml.com/pub/a/2003/05/14/py-xml.html
TODO:tocheck parsing file with libxml2 example -  https://www.programcreek.com/python/example/8012/libxml2.parseFile
Documentation - http://xmlsoft.org/python.html

pyXMLSec

Official documentation - http://pyxmlsec.labs.libre-entreprise.org/index.php?section=docs
Signing example - http://pyxmlsec.labs.libre-entreprise.org/index.php?section=examples&id=3

C documentation - https://www.aleksey.com/xmlsec/api/xmlsec-notes.html
xmlsec variables - http://pyxmlsec.labs.libre-entreprise.org/docs/html/index.html

Some examples -
https://github.com/pingali/pyAadhaarAuth/blob/master/AadhaarAuth/signature.py
http://ndg-security.ceda.ac.uk/browser/TI12-security/trunk/python/NDG/XMLSecDoc.py?rev=920

Mifare tags

Tag info

HF Tag B:

1x Mifare 1K

1x Mifare 4k

1x Mifare Ultralight Tag

LF Tag Bundle: 

EM4100

1x HID 1326 ProxCard II

1x T5577 Tags

There are also types:
“Mifare Classic 4k”
“Mifare Mini” each having a different memory size.
“Mifare Classic 1k” tag. 1k stands for the size of data the tag can store.
MIFARE Ultralight

RFID Technologies
HID iClass (13.56 MHz)
HID ProxCard (125 kHz)
EM4100x (125 kHz)
MIFARE Classic (13.56 MHz)

Manufacturer	Product	ATQA	SAK	ATS (called ATR for contact smartcards)	UID length
NXP	MIFARE Mini	00 04	09		4 bytes
	MIFARE Classic 1k	00 04	08		4 bytes
	MIFARE Classic 4k	00 02	18		4 bytes
	MIFARE Ultralight	00 44	00		7 byte
	MIFARE DESFire	03 44	20	75 77 81 02 80	7 bytes
	MIFARE DESFire EV1	03 44	20	75 77 81 02 80	7 bytes
IBM	JCOP31	03 04	28	38 77 b1 4a 43 4f 50 33 31	4 bytes
	JCOP31 v2.4.1	00 48	20	78 77 b1 02 4a 43 4f 50 76 32 34 31	7 bytes
	JCOP41 v2.2	00 48	20	38 33 b1 4a 43 4f 50 34 31 56 32 32	7 bytes
	JCOP41 v2.3.1	00 04	28	38 33 b1 4a 43 4f 50 34 31 56 32 33 31	4 bytes
Infineon	MIFARE Classic 1k	00 04	88		4 bytes
Gemplus	MPCOS	00 02	98
Innovision R&T	Jewel	0C 00
Nokia	MIFARE Classic 4k - emulated (6212 Classic)	00 02	38		4 bytes
	MIFARE Classic 4k - emulated (6131 NFC)	00 08	38		4 bytes

Tools: 

MIFARE Classic RFID-Tags - https://github.com/ikarus23/MifareClassicTool

About:
Mifare Classic in general is stated insecure, because it’s encryption protocol has been cracked. More detailed Information about this can be found in the following links:

A Mifare Classic 1k tag contains 16 sectors. Each of these sectors has 3 blocks of data storage and 1 block for storing the secret access keys and access controls. Each block contains 16 bytes of data. Before reading a sector, the reader must authenticate to the tag with a secret access key. Each sector has two keys: Key A and Key B Each of the 16 sectors can define it’s own access right and wich key is needed for a particular action. As an example you can define to use Key A for reading the block and Key B for writing to it. Sector 0 Block 0 also contains a non changeable UID (the tags unique ID) and some manufacturer data. This section is only writeable on some special chinese tags.

About:

 MF1S50yyX/V1

• Authentication: Preceding any memory operation the authentication procedure ensures that access to a block is only possible via the two keys specified for each block
• Crypto unit: The CRYPTO1 stream cipher of the MF1S50yyX/V1 is used for authentication and encryption of data exchange. • EEPROM: 1 kB is organized in 16 sectors of 4 blocks. One block contains 16 bytes. The last block of each sector is called “trailer”, which contains two secret keys and programmable access conditions for each block in this sector.

8.2.4 Three pass authentication
After selection of a card the reader specifies the memory location of the following memory access and uses the corresponding key for the three pass authentication procedure. After a successful authentication all commands and responses are encrypted. Remark: The HLTA command needs to be sent encrypted to the PICC after a successful authentication in order to be accepted.

8.2.5 Memory operations
After authentication any of the following operations may be performed:

• Read block 
• Write block 
• Decrement: Decrements the contents of a block and stores the result in the internal Transfer Buffer 
• Increment: Increments the contents of a block and stores the result in the internal Transfer Buffer 
• Restore: Moves the contents of a block into the internal Transfer Buffer 
• Transfer: Writes the contents of the internal Transfer Buffer to a value block

8.4 Three pass authentication sequence

1. The reader specifies the sector to be accessed and chooses key A or B. 
2. The card reads the secret key and the access conditions from the sector trailer. Then the card sends a number as the challenge to the reader (pass one). 
3. The reader calculates the response using the secret key and additional input. The response, together with a random challenge from the reader, is then transmitted to the card (pass two). 
4. The card verifies the response of the reader by comparing it with its own challenge and then it calculates the response to the challenge and transmits it (pass three). 
5. The reader verifies the response of the card by comparing it to its own challenge. After transmission of the first random challenge the communication between card and reader is encrypted.

8.6.1 Manufacturer block
This is the first data block (block 0) of the first sector (sector 0). It contains the IC manufacturer data. This block is programmed and write protected in the production test. The manufacturer block is shown in Figure 6 and Figure 7 for the 4-byte NUID and 7-byte UID version respectively.


The MF1S50yyX/V1 product family offers two delivery options for the UID which is stored
in block 0 of sector 0.

• 7-byte UID
• 4-byte NUID (Non-Unique ID)

Vilniečio kortele:
UID: ** ** ** ** (4 byte)
RF technology: ISO/IEC 14443,Type A
Tag type: MIFARE Classic 4k, NXP / ISO 14443-3a
Memory size: 4096 byte
Block Size: 16 byte
Number of sectors: 40
Number of blocks: 256

MF1S7035DUC: MIFARE® Classic 4K - Mainstream contactless smart card IC for fast and easy solution development

1.3 Security

• Manufacturer programmed 4 byte Non-Unique IDentifier (NUID) for each device
• Mutual three pass authentication (ISO/IEC DIS 9798-2)
• Individual set of two keys per sector to support multi-application with key hierarchy
• Features
• Contactless transmission of data and supply energy
• Operating distance up to 100 mm depending on antenna geometry and reader configuration
• Operating frequency of 13.56 MHz
• Data transfer of 106 kbit/s
• Data integrity of 16-bit CRC, parity, bit coding, bit counting
• Anti-collision
• Typical ticketing transaction time of less than 100 ms (including backup management)

2.1 EEPROM

• 4 kB, organized in 32 sectors of 4 blocks and 8 sectors of 16 blocks (one block consists of 16 byte)
• User definable access conditions for each memory block
• Data retention time of 10 years
• Write endurance 100.000 cycles

Memory layout of a Mifare Classic tag

The MIFARE Classic 1K offers 1,024 bytes of data storage, split into 16 sectors; each sector is protected by two different keys, called A and B. Each key can be programmed to allow operations such as reading, writing, increasing value blocks, etc. 

MIFARE Classic 4K offers 4,096 bytes split into forty sectors, of which 32 are same size as in the 1K with eight more that are quadruple size sectors. 

MIFARE Classic mini offers 320 bytes split into five sectors. For each of these card types, 16 bytes per sector are reserved for the keys and access conditions and can not normally be used for user data. Also, the very first 16 bytes contain the serial number of the card and certain other manufacturer data and are read only. That brings the net storage capacity of these cards down to 752 bytes for MIFARE Classic 1K, 3,440 bytes for MIFARE Classic 4K, and 224 bytes for Mini. It uses an NXP proprietary security protocol (Crypto-1) for authentication and ciphering.

Meanings:

• 1K and  4K are memory version,
• UID
• A UID is not a “serial number”, but a unique identifier. There is no recommendation how to turn the array of bytes into an integer.`
• “UID” is a common expression, defined in the ISO/IEC 14443-3. In some case the UID is even not unique like RID, NUID (FNUID and ONUID) see below
• The 4 byte UID is called “Single Size UID”, too. The 7 byte UID is called “Double Size UID”, too. The 10 byte UID is called “Triple Size UID”, too.
• 1 byte = 2 Hex-Characters
• 1 Hex-Characters = 4 bits 
• Sectors
• Sector 0 = Blocks 0 to 3
• Sector 1 = Blocks 4 to 7
• Sector 2 = Blocks 8 to 11
• 1 Sector = 16 byte = 32 Hex-Characters = 128 bits

Magic tags

• magic tag generation 1,  needs special chinese backdoor commands.  These are 7bits cmds and NFC enabled phone can not use them.
• magic tag generation 2.  Only need a normal write command to write to block0. NFC enabled phones can use this one, but some phones might not be able to write to block 0 because of software limits anyway.
• A Gen2 tag can be bricked quite easily and Gen1 tags is easily identified as magic so countermeasures in valid readers exists.

Questions:

 MIFARE Classic MF = The MF1S50yyX/V1 ???

Resources

Software + hardware:
Wiki free nfc tools - http://nfc-tools.org/index.php?title=ISO14443A
Hardvare + Software + tutorials - https://github.com/micolous/metrodroid/wiki/Cracking-keys
Multiple cards - Chamelion - https://shop.kasper.it/chameleonmini/170/chameleonmini-revg-color
Mifare Classic - https://github.com/nfc-tools/mfoc

NFC tools:
Locale NFC Plugin - https://play.google.com/store/apps/details?id=se.badaccess.locale.nfc&hl=en

Tutorial:
https://firefart.at/post/how-to-crack-mifare-classic-cards/

Info:

MIFARE Classic MF  datasheet - https://www.nxp.com/docs/en/data-sheet/MF1S50YYX_V1.pdf 
https://en.wikipedia.org/wiki/MIFARE
https://forum.xda-developers.com/showthread.php?t=1706057&page=6
Forum - http://www.proxmark.org/forum/viewtopic.php?id=1829
About  Proxmark3 - https://www.youtube.com/watch?v=W22juSqhJSA
About magic cards - http://www.proxmark.org/forum/viewtopic.php?id=3793
Xda NFC forum - https://forum.xda-developers.com/hardware-hacking/nfc

XML Signature

XML Signature (also called XMLDSig, XML-DSig, XML-Sig) defines an XML syntax for digital signatures and is defined in the W3C recommendation XML Signature Syntax and Processing. Functionally, it has much in common with PKCS#7 but is more extensible and geared towards signing XML documents. It is used by various Web technologies such as SOAP, SAML, and others.

XML signatures can be used to sign data–a resource–of any type, typically XML documents, but anything that is accessible via a URL can be signed. An XML signature used to sign a resource outside its containing XML document is called a detached signature; if it is used to sign some part of its containing document, it is called an enveloped signature; if it contains the signed data within itself it is called an enveloping signature.

• ?means the preceding item appears 0 or 1 times.
• +means the preceding item appears 1 or more times.
• *means the preceding item appears 0 or more times.

Example:
                <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
                    <SignedInfo>
                        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                        <Reference URI="">
                            <Transforms>
                                <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                            </Transforms>
                            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                            <DigestValue>...</DigestValue>
                        </Reference>
                    </SignedInfo>
                    <SignatureValue>...</SignatureValue>
                    <KeyInfo>
                        <X509Data>
                            <X509SubjectName>...</X509SubjectName>
                            <X509Certificate>...................</X509Certificate>
                        </X509Data>
                    </KeyInfo>
                </Signature>

            <Seal xmlns="http://resource">
                <ReceivedTime xmlns="http://resource">2017-12-12+02:00</ReceivedTime>
                <SignaturesOK xmlns="http://resource">true</SignaturesOK>
            </Seal>



Soap signature:

<env:Envelope
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
    <env:Header>
        <SOAP-SEC:Signature
            xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"env:actor="http://foo.example/bar"env:mustUnderstand="1">
            <ds:Signature
                xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:SignedInfo>
                    <ds:CanonicalizationMethodAlgorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
                    <ds:SignatureMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
                    <ds:Reference URI="#Body">
                        <ds:Transforms>
                            <ds:TransformAlgorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
                        </ds:Transforms>
                        <ds:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                        <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
                    </ds:Reference>
                </ds:SignedInfo>
                <ds:SignatureValue>rMzv774yMoCLi8kHB23q6rva2hs5OreamqFwcFDg4AaXl0qhoYQGBg==</ds:SignatureValue>
            </ds:Signature>
        </SOAP-SEC:Signature>
    </env:Header>
    <env:BodySOAP-SEC:id="Body"
        xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12">
        <m:GetLastTradePrice
            xmlns:m="http://example.com/trade">
            <m:symbol>EXAMPLE</m:symbol>
        </m:GetLastTradePrice>
    </env:Body>
</env:Envelope>

KeyInfo example:

<KeyInfo>

    <X509Data>

        <!-- two pointers to certificate-A -->

        <X509IssuerSerial>

            <X509IssuerName>CN=TAMURA Kent, OU=TRL,O=IBM, L=Yamato-shi, ST=Kanagawa,C=JP</X509IssuerName>

            <X509SerialNumber>12345678</X509SerialNumber>

        </X509IssuerSerial>

        <X509SKI>31d97bd7</X509SKI>

    </X509Data>

    <X509Data>

        <!-- single pointer to certificate-B -->

        <X509SubjectName>Subject of Certificate B</X509SubjectName>

    </X509Data>

    <X509Data>

        <!-- certificate chain -->

        <!--Signer cert,issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->

        <X509Certificate>MIICXTCCA..</X509Certificate>

        <!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=USissuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->

        <X509Certificate>MIICPzCCA...</X509Certificate>

        <!-- Root cert,subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->

        <X509Certificate>MIICSTCCA...</X509Certificate>

    </X509Data>

</KeyInfo>

Reference elements identify the data that is digested. Each Reference element identifies the data via a URI. In this example, the value of the URI is the empty String (""), which indicates the root of the document.

X509SubjectName element, which contains an X.509 subject distinguished name that should comply with [RFC 2253]

X509Certificate element, which contains a base-64 encoded X509 V.3 certificate

Info about private key:
$ openssl x509 -in Visma_MinaMeddelanden_SignCertTest.pem  -text -noout

From Wikipedia:

• The SignedInfo element contains or references the signed data and specifies what algorithms are used.
• The SignatureMethod and CanonicalizationMethod elements are used by the SignatureValue element and are included in SignedInfo to protect them from tampering.
• One or more Reference elements specify the resource being signed by URI reference; and any transforms to be applied to the resource prior to signing. A transformation can be a XPath-expression that selects a defined subset of the document tree.[1]
• DigestMethod specifies the hash algorithm before applying the hash.
• DigestValue contains the Base64 encoded result of applying the hash algorithm to the transformed resource(s) defined in the Reference element attributes.
• The SignatureValue element contains the Base64 encoded signature result - the signature generated with the parameters specified in the SignatureMethod element - of the SignedInfo element after applying the algorithm specified by the CanonicalizationMethod.
• KeyInfo element optionally allows the signer to provide recipients with the key that validates the signature, usually in the form of one or more X.509 digital certificates. The relying party must identify the key from context if KeyInfo is not present.
• The Object element (optional) contains the signed data if this is an enveloping signature.

Validation and security considerations
When validating an XML Signature, a procedure called Core Validation is followed.

1. Reference Validation: Each Reference's digest is verified by retrieving the corresponding resource and applying any transforms and then the specified digest method to it. The result is compared to the recorded DigestValue; if they do not match, validation fails.
2. Signature Validation: The SignedInfo element is serialized using the canonicalization method specified in CanonicalizationMethod, the key data is retrieved using KeyInfo or by other means, and the signature is verified using the method specified in SignatureMethod. Signature Validation: The SignedInfo element is serialized using the canonicalization method specified in CanonicalizationMethod, the key data is retrieved using KeyInfo or by other means, and the signature is verified using the method specified in SignatureMethod.

Fields explained

The <DigestMethod> element identifies the algorithm used to calculate the digest.
[s09-10] DigestMethod is the algorithm applied to the data after Transforms is applied (if specified) to yield the DigestValue. The signing of the DigestValue is what binds a resources content to the signer's key.

DigestMethod is a required element that identifies the digest algorithm to be applied to the signed object. This element uses the general structure here for algorithms specified in Algorithm Identifiers and Implementation Requirements (section 6.1).

If the result of the URI dereference and application of Transforms is an XPath node-set (or sufficiently functional replacement implemented by the application) then it must be converted as described in the Reference Processing Model (section  4.3.3.2). If the result of URI dereference and application of transforms is an octet stream, then no conversion occurs (comments might be present if the Canonical XML with Comments was specified in the Transforms). The digest algorithm is applied to the data octets of the resulting octet stream.

The <DigestValue>:

This value is the resulting hash derived from encrypting the contents of the message (be it the assertion or the entire response, as per your configuration).

DigestValue is an element that contains the encoded value of the digest. The digest is always encoded using base64 [MIME].

One way to make DigestValue:
$ openssl dgst -binary -sha1 some_file.txt | openssl enc -base64

The <CanonicalizationMethod> element indicates the algorithm was used to canonize the <SignedInfo> element.
CanonicalizationMethod is a required element that specifies the canonicalization algorithm applied to the SignedInfo element prior to performing signature calculations. This element uses the general structure for algorithms described in Algorithm Identifiers and Implementation Requirements (section 6.1). Implementations MUST support the REQUIRED canonicalization algorithms.

The <SignatureMethod> element identifies the algorithm used to produce the signature value.
The ds:SignedInfo/ds:SignatureMethod element specifies what type of signature—e.g., Kerberos or RSA—is used to create the signature. Taken together, these two elements tell us how to create the digest, and how to protect it from modification.

<SignatureValue>
Another method to protect the digest is to use public-key cryptography, such as RSA. In public-key cryptography, there are two keys, a private key, known only to the holder, and a public key, accessible to anyone who wants to communicate with the key holder. In public-key cryptography, anything encrypted with the private key can be decrypted with the public key, and vice versa.

<Transforms>
One or more Reference elements specify the resource being signed by URI reference; and any transforms to be applied to the resource prior to signing. A transformation can be a XPath-expression that selects a defined subset of the document tree.[1]

SignatureValue value  = Encrypt hash  DigestValue with RSA private key and base64result

X509Certificate value = is certificate, that holds RSA public key

Process

1. Determine which resources are to be signed.
This will take the form of identifying the resources through a Uniform Resource Identifier (URI).
<Reference URI=""> part.

2. Calculate the digest of each resource. DigestValue

In XML signatures, each referenced resource is specified through a <Reference> element and its digest (calculated on the identified resource and not the <Reference> element itself) is placed in a <DigestValue> child element like

3. Collect the Reference elements

Collect the <Reference> elements (with their associated digests) within a <SignedInfo> element like

The <CanonicalizationMethod> element indicates the algorithm was used to canonize the <SignedInfo> element. Different data streams with the same XML information set may have different textual representations, e.g. differing as to whitespace. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. The <SignatureMethod> element identifies the algorithm used to produce the signature value.

4. Signing

Calculate the digest of the <SignedInfo> element, sign that digest and put the signature value in a <SignatureValue> element.

5. Add key information

If keying information is to be included, place it in a <KeyInfo> element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification.

6. Enclose in a Signature element

Place the <SignedInfo>, <SignatureValue>, and <KeyInfo> elements into a <Signature> element. The <Signature> element comprises the XML signature.

Verifying an XML Signature
A brief description of how to verify an XML signature:


1. Verify the signature of the <SignedInfo> element. To do so, recalculate the digest of the <SignedInfo> element (using the digest algorithm specified in the <SignatureMethod> element) and use the public verification key to verify that the value of the <SignatureValue> element is correct for the digest of the <SignedInfo> element.


2. If this step passes, recalculate the digests of the references contained within the <SignedInfo> element and compare them to the digest values expressed in each <Reference> element's corresponding <DigestValue> element.

XML Signature: How to calculate the digest value?

I came across this question when attempting to find out the exact same thing. I later worked out how to do it, so figured I'd post the answer here.

The things that need to happen are:

canonicalization

create digest value, typically SHA1 (but could be SHA256 amongst others)

base64 encode it

The canonicalization part was fairly simple, as the Java libraries did that for me. What I struggled with was the next bit, the creating of the digest, because I made a fatal error in that the SHA1 digest I generated was the SHA1 in HEX form. SHA1 is 160 bits, so 20 bytes, but if you output these 160 bits in HEX, you get 40 characters. If you then base64 encode that, you get totally the wrong value compared to what should be in the DigestValue.

Instead, you should generate the SHA1 digest and base64 encode the 20 byte output. Don't try to output the 20 bytes to STDOUT as it's highly unlikely to be readable (which is why people often output the HEX equivalent, since it is readable). Instead, just base64 encode the 20 bytes and that's your DigestValue.

Dictionary:

Canonicalization:
In computer science, canonicalization (sometimes standardization or normalization) is a process for converting data that has more than one possible representation into a "standard", "normal", or canonical form.
A Canonical XML document:
By definition an XML document that is in XML Canonical form, defined by The Canonical XML specification. Briefly, canonicalization removes whitespace within tags, uses particular character encodings, sorts namespace references and eliminates redundant ones, removes XML and DOCTYPE declarations, and transforms relative URIs into absolute URIs.
Message digest: 
Are functions that convert sequences of bits, possibly quite long, called messages, into fixed-length binary "fingerprints" or message digests of the original sequences.
Digital Signatures:
You can use public key authentication to produce "digital signatures." These signatures have a very desirable characteristic—namely, it is computationally infeasible for anyone without the private key to produce a signature that will verify for a given message. Modern digital signatures consist of (1) a message and a message digest of that message asymmetrically transformed under a private key of the signer.
A Message Authentication Code (MAC)
MACs are syntactically identical to signatures but imply a shared secret key.
MAC and signature algorithms are syntactically identical, but a signature implies public key cryptography.

Acronyms:
ASP Active Server Pages
API Application Programming Interface
BOM Byte Order Mark
CR Carriage Return
CSS Cascading Style Sheets
COM Component Object Model
UTC Coordinated Universal Time
DOM Document Object Model
DTD Document Type Definition
XML Extensible Markup Language
XSL Extensible Stylesheet Language
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IDL Interface Definition Language
ISO International Standards Organization
IETF Internet Engineering Task Force
JDK Java Development Kit
JSP Java Server Pages
LF Line Feed
MIME Multipurpose Internet Mail Extensions
NCName Non-colonized Name
OMG Object Management Group
QName Qualified Name
RPC Remote Procedure Call
RFC Request For Comments
SAX Simple API for XML
SOAP Simple Object Access Protocol
SQL Strutured Query Language
UTF Unicode Transformation Format
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
UCS Universal Character Set
VB Visual Basic
WD Working Draft
W3C World Wide Web Consortium
XInclude XML Inclusions
Infoset XML Information Set
XLink XML Linking Language
XPointer XML Pointer Language
XSLT XSL Transformations

Python library for signing;

xmlsec - documentation.
pyXMLSec - Documnetation

Resources:

https://www.xml.com/pub/a/2001/08/08/xmldsig.html

https://www.w3.org/TR/xmldsig-core/

https://www.youtube.com/watch?v=UYQPkWDaHHM - video apie XML enveloped Signature

https://docs.oracle.com/cd/E27515_01/common/tutorials/content_sign_message.html

https://www.w3.org/TR/xmldsig-core/
https://msdn.microsoft.com/en-us/library/ms996502.aspx - Digital Signature Cryptography
https://stackoverflow.com/questions/24961073/is-that-what-exactly-does-the-enveloped-signature-transform - About enveloped signature transform
https://www.di-mgt.com.au/xmldsig2.html - Comprehensive tutorial
https://www.decalage.info/en/python/xmldsig - python libraries
https://www.di-mgt.com.au/xmldsig.html - detailed signing process

python lxml

>> root = etree.Element("root")
>> etree.tostring(root)


Create html document:
>>> html = etree.Element("html")
>>> body = etree.SubElement(html, "body")
>>> body.text = "Added text" # tail adds text after tag
>>> etree.tostring(html)
b'<html><body>Added text</body></html>'

Creating elements with text elements

>>> root = etree.Element("root") 

>>> etree.SubElement(root, "child").text = "Child 1" 

>>> etree.SubElement(root, "child").text = "Child 2" 

>>> etree.SubElement(root, "another").text = "Child 3"

Display only textual data:

>>> etree.tostring(html, method="text")

>>> print(html.xpath("string()")) 

>>> print(html.xpath("//text()")) #Display textual data as list

Iteration:

>>> [(x.tag, x.text) for x in root.iter()]

> [ child.tag for child in root ] # root child element itteration

Finding elements: 

>> print(root.find(".//b").tag)

>>> [ b.tag for b in root.iterfind(".//b") ] # Finding multiple elements

Dumping xml:
xml.etree.ElementTree.dump(tree)

http://lxml.de/index.html - Official website.
http://lxml.de/3.8/lxmldoc-3.8.0.pdf - Documentation

bitcoin configuration options

############################################################
#  Bitcoin-cash                                          #
#                                                          #
#  To start bitcoin:                               #
#      # systemctl start bitcoind                          #
#  To communicate with bitcoin-classic as a normal user:   #
#      $ bitcoin-cli help                                  #
#                                                          #
#  Config:        /etc/bitcoin/bitcoin.conf                #
#  Blockchain:    /var/lib/bitcoind                        #
#                                                          #
############################################################

Before running bitcoin, you can specify configuration file:
$ bitcoin-qt -conf=/home/$USER/.bitcoin/bitcoin.conf

Generating key:

To generate private key:
$ walletpassphrase your-wallet-passphrase 300

Getting key:

The easiest way is to export your private keys using the dumpprivkey functionality.
DumpPrivKey: returns the wallet-import-format (WIP) private key corresponding to an address. (But does not remove it from the wallet.) Bitcoin Developer Reference

Dump private key:

$ dumpprivkey <your bitcoin address>

-prune=<n>
Reduce storage requirements by pruning (deleting) old blocks. This mode disables wallet support and is incompatible with -txindex. Warning: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, >%u = target size in MiB to use for block files)

A value of 0 disables pruning. The minimal value above 0 is 550.Where 550 is the size in MB you want the node to ocupy in your system.



Give Higher CPU Priority to Bitcoin-Qt Process

$ sudo renice -20 -p 2202

-20 is the nice value a value between -20 and +19. The lower the nice value, the higher priority the process gets.

$ sudo renice -20 -p `pgrep bitcoin-qt`

Other interesting options:

RPC server options:

-server Accept command line and JSON-RPC commands
-rest Accept public REST requests (default: 0)
-rpcuser=<user> Username for JSON-RPC connections
-rpcpassword=<pw> Password for JSON-RPC connections
-conf=<file> Specify configuration file (default: bitcoin.conf)
-addnode=<ip> Add a node to connect to and attempt to keep the connection open
-onion=<ip:port> Use separate SOCKS5 proxy to reach peers via Tor hidden services (default: -proxy)

Connection options:

-port=<port> Listen for connections on <port> (default: 8333 or testnet: 18333)

-proxy=<ip:port> Connect through SOCKS5 proxy

-proxyrandomize Randomize credentials for every proxy connection. This enables Tor stream isolation (default: 1)

-torcontrol=<ip>:<port> Tor control port to use if onion listening enabled (default: 127.0.0.1:9051)

-torpassword=<pass> Tor control port password (default: empty)

Wallet options:

-disablewallet Do not load the wallet and disable wallet RPC calls

-mintxfee=<amt> Fees (in BTC/kB) smaller than this are considered zero fee for transaction creation (default: 0.00001)

-paytxfee=<amt> Fee (in BTC/kB) to add to transactions you send (default: 0.00)

-rescan Rescan the block chain for missing wallet transactions on startup

-salvagewallet Attempt to recover private keys from a corrupt wallet on startup

-wallet=<file> Specify wallet file (within data directory) (default: wallet.dat)


Other:
Transferring from bitcoin fullnode to electrum.
https://en.bitcoin.it/wiki/Transferring_coins_from_Bitcoin-Qt_to_Electrum