SEAL is a Secure Evidence Attribution Label. It permits signing media for attribution.
This is an implementation of SEAL in C. The specifications are at: https://github.com/hackerfactor/SEAL
This code:
- Generates keys. The private key should be kept private. The public key is ready to be uploaded to your DNS TXT record.
- Sign files using the private key. It also supports using a remote signing service.
- Validating signatures. This only requires DNS access. For testing/debugging, you can specify the public key DNS TXT file that you generated.
See the BUILD file for compiling and usage.
This code currently supports static-files only. It does not support streaming data. (The SEAL protocol supports streaming data, but this implementation does not (yet).)
| Image Format | Read Support | Write Support |
|---|---|---|
| JPEG | Yes | Yes |
| PNG | Yes | Yes |
| GIF | Yes | Yes |
| WEBP | Yes | Yes |
| HEIC | Yes | Yes |
| AVIF | Yes | Yes |
| PNM/PPM/PGM | Yes | Yes |
| SVG | Yes | Yes |
| TIFFⁱ | Yes | Yes |
| JPEG XLⁱⁱ | Yes | Yes |
| DICOM | Yes | Yes |
| BMP | No (no metadata support) | No (no metadata support) |
| FAX | No | No. Seriously, just no. |
ⁱ TIFF includes many camera-raw formats, including Adobe Digital Negative (DNG), Canon CRW and CR2, Hasselblad 3FR, Kodan KDC, Leica RAW, Nikon NEF, Panasonic Raw, Sony ARW, and many more.
ⁱⁱ JPEG XL uses ISO-BMFF for storing metadata and can be signed using SEAL. The raw JPEG XL stream does not support metadata and cannot be signed by SEAL.
| Audio Format | Read Support | Write Support |
|---|---|---|
| AAC | Yes | Yes |
| AVIF | Yes | Yes |
| M4A | Yes | Yes |
| MKA | Yes | Yes |
| MP3 | Yes | Yes |
| MP3+ID3 | Yes | Yes |
| MPEG | Yes | Yes |
| WAV | Yes | Yes |
| Video Format | Read Support | Write Support |
|---|---|---|
| MP4 | Yes | Yes |
| 3GP | Yes | Yes |
| AVI | Yes | Yes |
| AVIF | Yes | Yes |
| HEIF | Yes | Yes |
| HEVC | Yes | Yes |
| DIVX | Yes | Yes |
| MKV | Yes | Yes |
| MOV/Quicktime | Yes | Yes |
| MPEG | Yes | Yes |
| WEBM | Yes | Yes |
| Document Format | Read Support | Write Support |
|---|---|---|
| Yes | Yes | |
| XML | Yes | Yes |
| HTML | Yes | Yes |
| Plain Text | Yes | Yes |
| OpenDocument (docx, pptx, etc.) | Yes via ZIP | Yes via ZIP |
| Electronic Publication (epub) | Yes via ZIP | Yes via ZIP |
| Package Format | Read Support | Write Support |
|---|---|---|
| Java Archive (JAR) | Yes via ZIP | Yes via ZIP |
| Android Application Package (APK) | Yes via ZIP | Yes via ZIP |
| iOS Application Archive (iPA) | Yes via ZIP | Yes via ZIP |
| Mozilla Extension (XPI) | Yes via ZIP | Yes via ZIP |
| Container Format | Read Support | Write Support | About |
|---|---|---|---|
| EXIF | Yes | Yes: See Manual Signing | EXIF is a standard format for storing metadata. It is often found in JPEG, PNG, and a few other file formats. SEAL supports all top-level EXIF records. (Nested EXIF records are unsupported due to the ambiguous scope.) |
| XMP | Yes | Yes: See Manual Signing | XMP is a standard text-based format for storing metadata. It may appear in a wide range of files. SEAL supports all top-level XMP records. (Nested XMP records are unsupported due to the ambiguous scope.) |
| RIFF | Yes | Yes | The Resource Interchange File Format (RIFF) is a container format used by WAV, AVI, and a few other (less common) media files. SEAL supports all RIFF-based files. |
| ISO-BMFF | Yes | Yes | ISO's Base Media File Format (BMFF, also called ISO-14496) is a container format used by MP4, 3GP, HEIF, HEIC, AVIF, DIVX, and many other common media files. SEAL supports all ISO-BMFF files. |
| Matroska | Yes | Yes | Matroska is a flexible container format used by WebM, MKV (video), and MKA (audio). SEAL supports all Matroska-based media files. |
| ZIP | Yes | Yes | ZIP is an archive container that can hold multiple files. OpenDocument formats (docx, odt, pptx, epub, etc.), common package archives, and more bundle their files in ZIP archives. |
| ZIP64 | Yes | Yes | ZIP64 is an extension to ZIP that supports extremely large files. (Regular ZIP has a maximum of 65,535 files and the total archive can be no larger than 4 gigabytes (4GB). ZIP64 permits 18 quintillion files with a maximum size of 16 exabytes (16EB; that's 1.8×1019 bytes). |
This is not every file format that sealtool supports! Many formats are based on other formats. (CR2 is based on TIFF, DIVX is based on RIFF, etc.). Similar formats are likely already supported. sealtool will only parse files when it recognizing the file format.
Have a format you need that isn't supported? Let us know!
All media formats (both known and unknown), and all read-only media, can be supported through the use of a sidecar. A sidecar stores the SEAL record in a separate file. This way, you can sign real-only media, such as a forensic drive image or legal evidence, without altering the source media.
Some file formats are self-contained, such as PNG and JPEG. Some are multi-file but bundled into a container, such as JAR and OOXML files (pptx, docx, etc.). In these cases, a ZIP file holds the manifest and the separate dependency files.
However, some data formats are unbundled collections of files. These are common when the data files are too large to compress/decompress as needed or when the files are intended to be memory mapped. Examples include NASA's Planetary Data System (PDS, including PDS3 and PDS4) and Shapefile for storing geospatial vector data. In these instances, the directory contains a specific manifest file that identifies the various adjacent data files.
Because individual data files often contain compact binary formats, they cannot be directly signed using SEAL. Fortunately, a sidecar can be placed in the directory that identifies and signs signatures that cover each of the external files in the directory. This permits signing unbundled multi-file formats.
In some cases, the SEAL signature can be embedded directly in the manifest file. Unfortunately, many of these file formats use outdated implementations that do not fully support the standards. For example, the GDAL package is used for managing PDS4 files. However, GDAL uses a 1024-byte probe window to detect file formats; if the XML header preceding the first element tag exceeds 1024 bytes, GDAL will fail to recognize the file. For maximum compatibility, use a standalone SEAL sidecar.
Other multi-file formats require every file in the directory to be tracked by the manifest. Examples, include the Digital Cinema Package (DCP) and Interoperable Master Format (IMF) for audio/video production, and BagIt for tracking digital evidence. Because these formats require every file within the package directory to be inventoried and checksummed, an untracked sidecar would invalidate the package. For these formats, the SEAL sidecar should be placed in the parent directory, above the directory that contains the format data, which keeps it outside the integrity boundary of the package. (Adding the sidecar to the manifest is not feasible because these manifests each includes a checksum for every listed file, creating a circular dependency.)
To link a SEAL sidecar to its associated manifest or directory, the sidecar should use the same base name (preserving case). For example, if the PDS4 manifest is Data1.xml, the SEAL sidecar should be Data1.seal. Similarly, if the DCP directory is concert27/, the sidecar should be concert27.seal, using the directory name without the trailing path separator.