A log record's evidentiary value rests on two separate questions: "who performed this action" and "was this record altered afterward." The first question is answered by an identity-matched access record; the second is answered by the integrity layer formed jointly by a hash chain, a digital signature, a daily timestamp, and an automatic check that runs every night. These four mechanisms don't work separately — they work together.
"Who" isn't enough — you also need "unaltered"
A plain text log file can easily be corrupted by anyone with access to the disk — a line added, deleted, or changed — and proving afterward that such a change was made is nearly impossible. For a record to genuinely carry evidentiary weight, it must be possible to show, independently, that it hasn't changed since the moment it was produced. This is a separate, additional layer, entirely apart from identity matching.
How the hash chain works
izgate writes traffic records to the archive in segments, organized by tenant/device/type/day. When each segment closes, a SHA-256 digest (hash) is computed from its contents; this digest is produced so that it also incorporates the digest of the segment before it. The result works like a chain: segment 2's digest carries segment 1's digest, segment 3's digest carries segment 2's digest, and so on. If any segment in the past is altered, that segment's digest no longer holds up, and the entire chain after it becomes "broken" — this break, including exactly where it starts, is detected during verification.
Hourly segment closure
Segments close on the hour; that is, every hour, the traffic record for that hour is finalized and added to the chain. This keeps the proof of integrity from spreading across very large time windows: if a problem occurs, which hourly segment was affected can be identified quickly. The database used for live search and this signed archive are kept on separate physical disks; one filling up or failing doesn't affect the other.
Ed25519 signature: a key unique to your installation
While the hash chain shows integrity (that nothing was altered), the signature proves origin. Each segment is signed with an Ed25519 key unique to your installation; this signature shows that the segment genuinely came from your own izgate installation and wasn't produced elsewhere and inserted. A file produced without a signature, or signed with a different key, fails verification.
Why a single file digest isn't enough
The simplest method one might think of is computing a single digest (hash) for each segment on its own and storing it somewhere. The flaw in this approach is this: if the segment itself and that digest are changed together, the "new" digest matches the "new" content and no contradiction appears. Chaining (each digest also carrying the one before it) closes this gap: changing a segment and its digest together isn't enough, because the following segment's digest was still computed against the "old" digest. For an attacker to produce a consistent fake chain, they would need to re-sign every segment in the chain from that point onward — which isn't possible without access to the private key unique to your installation.
The daily qualified timestamp
Law No. 5070 on Electronic Signatures defines a timestamp as follows:
"Zaman damgası: Bir elektronik verinin, üretildiği, değiştirildiği, gönderildiği, alındığı ve / veya kaydedildiği zamanın tespit edilmesi amacıyla, elektronik sertifika hizmet sağlayıcısı tarafından elektronik imzayla doğrulanan kaydı,"
"Timestamp: a record verified by electronic signature by an electronic certificate service provider, for the purpose of determining the time at which an electronic data item was produced, altered, sent, received, and/or recorded,"
Law No. 5070 on Electronic Signatures, Article 3/h — mevzuat.gov.tr — unofficial translation
The Regulation explicitly requires this proof for internet public use providers acting for commercial purposes:
"(d) bendi gereğince kaydedilen bilgileri ve bu bilgilerin doğruluğunu, bütünlüğünü ve gizliliğini teyit eden değeri kendi sistemlerine günlük olarak kaydetmek ve bu verileri iki yıl süre ile saklamak,"
"To record, on a daily basis in their own systems, the information logged under clause (d) and a value confirming the accuracy, integrity, and confidentiality of that information, and to retain this data for a period of two years,"
Regulation on Internet Public Use Providers, Article 5/1-e — mevzuat.gov.tr — unofficial translation
This provision is written directly only for commercial-purpose providers; the legislation does not make the word "timestamp" mandatory for general public use providers. Regardless of this distinction, izgate obtains one qualified timestamp per day in every installation (from a timestamp service provider such as Kamu SM); this independently confirms that the record existed on that date, outside of your own organization, and shows that the signature wasn't applied after the fact.
Automatic verification every night
An automatic integrity check that runs every night re-checks the hash, signature, and timestamp of the segments in the chain. This prevents a corruption from going unnoticed for months — it is caught on the very night it occurs, in that night's verification, and a critical alert is generated, so a response can begin without delay. This verification runs on its own and on a regular schedule in every installation, without waiting for a manual check.
What tampering looks like
Someone with access to the archive files deletes or alters a line inside a segment.
The altered segment's hash no longer matches the earlier calculation; every chain digest after this segment stops holding up too.
The nightly verification, or a manual verification from the panel, shows exactly which segment the chain broke from, and a critical alert is triggered.
One-click verification on the Archive page
You can verify the integrity of any segment, or of the entire chain, with one click from the Archive page: the file digest is compared against the catalog, the manifest signature against the installation key, and the chain against the previous segment's digest; the timestamp token is checked together with these. The result is reported as either "chain intact" or exactly where the error is.
Checklist
- Is your archive kept on a disk separate from the live database?
- Are segments protected by a hash chain and a digital signature?
- Is an independent timestamp obtained at least once a day?
- Does an automatic integrity check run every night?
- Do you get a critical alert if corruption occurs?
- Can you verify the chain with one click from the panel?
- Is the security of your installation's unique signing key ensured?
Frequently asked questions
What exactly does a hash chain prove?
Every archive segment's digest (hash) also includes the digest of the previous segment. So if a segment is altered or deleted in the past, every digest after that point no longer holds up and the chain breaks; that break is detected instantly during verification.
What does the Ed25519 signature do, and how is it different from the hash chain?
The hash chain proves integrity; the signature proves origin. A file that isn't signed with Ed25519, or is signed with a different key, fails verification.
Is a timestamp mandatory?
The legislation does not make the word "timestamp" mandatory for general public use providers. For internet public use providers acting for commercial purposes, Article 5/1-e of the Regulation requires a value confirming the accuracy, integrity, and confidentiality of records to be logged daily. izgate strengthens this proof in every installation by obtaining a qualified timestamp once a day.
How would I notice if tampering occurred?
An automatic integrity check that runs every night re-checks the hash, signature, and timestamp of every segment in the chain. If a segment has been altered or deleted, the chain breaks at that point; the system reports this as a critical alert, and the Archive page shows exactly which segment the problem is in.
How do I verify integrity from the panel?
You can verify the integrity of any segment, or the whole chain, with one click from the Archive page: the hash chain, signature, and timestamp are checked together; the result is reported as either "chain intact" or exactly where the error is.
Wouldn't storing a single segment's digest be enough?
No. If a segment and its digest are changed together, a digest stored on its own can't catch that change. Chaining closes this gap by making every digest also carry the one before it; changing one segment means re-signing the entire chain after that point.
This page is for information only; for the current text of the legislation, refer to the official source (mevzuat.gov.tr).
Related guides
Employee Internet Use: Who Is Responsible?
How an identity-matched record protects the business.
PracticeAuthority Requests Your Logs: What Should You Do?
How the signed package is prepared for a request.
PracticeContent Filtering Requirement and Safe Internet Service
Block records are stored in the same signed archive, too.
