Skip to content

If a sealed record changes later, verification shows it

When a workshop seals a job or an Ekspertiz centre approves a report, the record is signed and locked. If a single field changes afterwards, verification without an account shows it.

Technical architectureEmail the security team

OtoTasdik's security comes down to four topics

Below you can read which records are signed, how a signature is checked, where data is kept and how your account is protected. Each point describes the system as it runs today.

Workshop and Ekspertiz records are signed and chained per vehicle

Signed records
The work order behind each Service Statement, Ekspertiz reports and the maintenance history PDF are signed.
No edits after sealing
A sealed work order and an approved Ekspertiz report can no longer be edited.
One chain per vehicle
Every signed record carries the digest of the previous record on the same VIN, so a vehicle's records are linked in order.
Records that are not signed
Records owners add themselves (service, fuel, insurance, accident, fines and uploaded inspection reports, for example) and sale links are not signed.

Anyone can verify without an account

Report number or statement code
An Ekspertiz report is checked on the verification page by its report number (such as RPT-2026-0001). A Service Statement is checked by the 8-character code printed on it.
What verification checks
The server recomputes the record's digest and checks the signature. For a Service Statement it also checks the link to the previous record on the same vehicle.
Signing key
The signing key is kept in a key file on OtoTasdik's server. Its public half is published at an open address, so you can check a signature yourself without asking our server.
VIN and plate
Searching by VIN or plate is only open to signed-in users.

Records are stored in the EU, in Frankfurt

Data residency
Records are stored in the EU, in AWS's Frankfurt region (eu-central-1), and handled under Turkish data protection law (KVKK).
Document scan
If you choose to fill in a document from a photo, the photo goes to Google Gemini (Google LLC, USA) only after your explicit consent.
Encryption in transit
Connections use HTTPS. The panel (giris.ototasdik.com) and the API the apps connect to (api.ototasdik.com) send an HSTS header, so the browser opens these addresses over HTTPS only.
Your rights over your data
In the panel (giris.ototasdik.com) you can export each vehicle's history as JSON. You can delete your account in the app or in the panel.

Your account is protected by a password and optional two-step verification

Password
Your password is never stored as plain text; it is hashed one way with bcrypt.
Two-step verification
You can turn on two-step verification with an authenticator app (TOTP) in the settings. It is optional.
Session
When you sign in you get a short-lived access token and a separate token that renews it.
Encrypted secrets
Two-step verification secrets and credentials from external sign-in providers are encrypted in the database with AES-GCM.

A work order goes from opening to verification in four steps

  1. 01

    Work order

    The workshop opens the work order on the phone with the plate and the VIN, and records the work and the parts.

  2. 02

    Seal

    When the workshop seals the job, the work order's content is put into a fixed form and a digest is computed from it.

  3. 03

    Signature and chain

    The digest is signed with OtoTasdik's key together with the previous record's digest on the same vehicle, a sequence number and the signing time. From then on the record cannot be edited.

  4. 04

    Verification

    Anyone can verify the record with the 8-character code on the Service Statement. The server recomputes the digest and checks the signature and the link to the previous record.

Technical verification details

Security profile

Active
Digital signature
Ed25519
Digest and chain
SHA-256, per vehicle (VIN)
Canonical form
JSON, sorted keys
Time
Signing time is part of the signed data; no external timestamping
Key storage
Key file on the server; public key published
TLS
HTTPS, HSTS on panel and API connections
Session
JWT, access and refresh token
Password
bcrypt
MFA
TOTP, optional
Encrypted secrets
AES-GCM, MFA secrets and provider credentials
Data residency
eu-central-1 (Frankfurt, EU)

Service Statement (work order)

content_hash = sha256(canonical_json(work_order))
signature    = ed25519_sign(key, "v2|" + content_hash + "|" + previous_hash
                 + "|" + chain_index + "|" + chain_epoch + "|" + signed_at_unix)

Ekspertiz report

report_hash = sha256(canonical_json(report) + previous_hash + finalized_at)
signature   = ed25519_sign(key, report_hash)

previous_hash is the digest of the previous signed record on the same VIN; the first record uses a fixed starting value. canonical_json is JSON with its keys sorted alphabetically.

Have you found a vulnerability?

Send the finding straight to our security team. Please keep it private until a fix is out.

guvenlik@ototasdik.comsecurity.txt