This presentation by Anna-Grit Eggers (University of Goettingen) offers an overview on information decapsulation and restoration.
PERICLES is a four-year Integrated Project (2013-2017) funded by the European Union under its Seventh Framework Programme (ICT Call 9).
http://pericles-project.eu/
Exploring the Future Potential of AI-Enabled Smartphone Processors
PERICLES Decapsulation and Restoration
1. GRANT AGREEMENT: 601138 | SCHEME FP7 ICT 2011.4.3
Promoting and Enhancing Reuse of Information throughout the Content Lifecycle taking account of Evolving
Semantics [Digital Preservation]
“This project has received funding from the European Union’s
Seventh Framework Programme for research, technological
development and demonstration under grant agreement no601138”.
Anna-Grit Eggers (University of Goettingen)
2. Decapsulation is an integral part in the objective of encapsulation. A
user will at any point in time be able to access the encapsulated
information.
The decapsulation process can be facilitated by
◦ appending additional information to the payload before the encapsulation
◦ storing the decapsulation supporting information at a location different to the
payload.
Supporting information before decapsulation is called Restoration
Metadata.
The storage location, format, and used encapsulation technique to store
the restoration metadata need to be handled in a defined way
Sometimes it is not obvious which embedding algorithm was used, or even
if there is information embedded at all.
5. An Algorithm Identifier can facilitate the identification
of the used encapsulation technique.
It should best be stored at a defined and perceptible location
e.g. in a standard metadata field.
◦ It has to be defined which metadata field is used to guarantee the
recognition by the encapsulation and decapsulation tool.
◦ The original content of the metadata field has to be added to the
restoration metadata set, to be able to recover the object’s original
state.
Alternatively, a visible encapsulation algorithm can be
used to store this information.
6. For some algorithms it is necessary to store information
about the localisation of the restoration metadata.
Some need to store other algorithm configuration options
together with the algorithm identifier.
◦ This is the case if the restoration metadata location can
vary, depending on carrier constraints and algorithm
configurations.
The format of the localisation information can depend on the
referred algorithm.
7. “ALGORITHM_IDENTIFIER#LOCALISATION_INFORMATION”
the “#” is a separator between the algorithm identifier and the
localisation information:
image_frame_expansion_E#582
This translates to:
“The restoration metadata saved for the use of the algorithm that
expands images with an information frame towards east starts at
the pixel 582”.
This information would suffice for an information encapsulation
tool to know which algorithm to use and where to find the
restoration information, and then to execute the decapsulation.
8. It is not necessary to have an algorithm-independent format of the
locator:
audio_track_expansion#3
Here the location information refers to the third audio track of a video
where information was embedded by adding an additional audio track to
the video.
The localisation number at this identifier has a completely different
meaning compared to the first example
It suffices to initiate the decapsulation process.
Only the addressed decapsulation algorithm has to understand the
localisation information, and the IE framework has to understand the
algorithm identifier.
9. For many information encapsulation techniques it is possible
to identify whether information is encapsulated, and which
encapsulation technique was used based on obvious traits at
the file.
In this case it is not necessary to store algorithm identifier
and localisation information.
Still, this information supports the handling of hardly
detectable techniques, and helps to distinguish between
similar techniques.
11. • A checksum of the original
enables a validation of the restored information, carrier as well as payload
it ensures consistency.
• Configuration information and parameters (including the
encapsulation process itself)
needed to reverse the encapsulation algorithm
to know at decapsulation time
decisions made during the encapsulation process.
• Original file formats, encodings and paths of each file.
• If metadata fields are used, e.g. for the algorithm identifier, the
original entries of these fields need also to be saved.
• Localisation information, if they are needed.
• A ‘valid-until’ timestamp included in the restoration metadata can
indicate a date at which the payload has to be verified again.
12. • Other payload management information, such as semantic
annotations, to the restoration metadata can support the
handling of this information without the need to execute the
decapsulation process.
• All restoration metadata parameters have to be stored by the
encapsulation algorithms during the encapsulation process.
13. • Some embedding techniques, e.g. steganography, only
provide the restoration of the embedded payload, whereas
the carrier is not designed to be restored.
• Long-term preservation scenarios in which the carrier is a
valuable digital object require also the restoration of the
digital object.
• By storing additional information about the changes made on
the carrier digital object, and add a digit of the original digital
object, it could be possible to enable the digital object
restorability also for techniques which didn‘t originally provide
for this.