Security Considerations

Understanding DSPIP's shipping-specific threat model, privacy modes, key management, split-key anti-cloning protection, and delivery confirmation security.

Threat Model

DSPIP addresses shipping-specific threats through cryptographic signatures, privacy-preserving encryption, and physical anti-cloning mechanisms.

📦

Package Forgery

Mitigated

An attacker attempts to create a fake shipping label claiming to be from a legitimate sender.

Mitigation

Cryptographic signatures (ECDSA + SHA-256) cannot be forged without the private key. Verification against the DNS-published public key will fail for any forged label.

📋

QR Code Cloning

Mitigated

An attacker copies a valid QR code and applies it to a different package to redirect or duplicate shipments.

Mitigation

Split-key labels with Ed25519 key pairs prevent cloning. Copied QRs lack matching public keys revealed from physical scratch-off zones. Clone detection is instant at delivery.

🔒

Recipient Privacy Breach

Mitigated

Unauthorized parties (warehouse workers, transit handlers) access recipient personal information during transit.

Mitigation

Encrypted privacy mode uses ECIES + AES-256-GCM + HKDF-SHA256 to encrypt recipient data for the last mile provider only. Transit handlers see only the LMP destination, not the actual recipient address.

🚚

Delivery Fraud

Mitigated

False claims of delivery or non-delivery for fraud or theft purposes.

Mitigation

Cryptographic delivery confirmation via challenge-response protocol. Recipient signs challenge with their delivery key, providing non-repudiable proof. Multi-party attestation available for high-value shipments.

🔓

Package Tampering

Mitigated

An attacker modifies the shipping information (sender, recipient, or other data) after the QR code is created.

Mitigation

The signature covers all payload data. Any modification to the payload will cause signature verification to fail. Split-key scratch-offs show visual evidence of tampering.

🔁

Replay Attacks

Mitigated

An attacker reuses a valid shipping label for a different package or shipment.

Mitigation

Unique tracking IDs (itemId) and timestamps prevent reuse. Revocation lists allow senders to invalidate lost or stolen labels. Split-key labels are inherently single-use.

🕵

Man-in-the-Middle

Mitigated

An attacker intercepts DNS queries to return a malicious public key.

Mitigation

DNSSEC validation protects key lookups. DNS-over-HTTPS (DoH) provides additional transport layer security. Split-key mode bypasses DNS entirely.

🔍

Tracking Attacks

Mitigated

Attackers correlate shipping data to track individual behavior or package patterns.

Mitigation

Privacy modes prevent correlation: random tracking IDs, limited timestamp precision, unique encryption per package, and encrypted recipient information.

🔐 Physical Anti-Cloning Protection

For maximum security, DSPIP offers split-key labels with Ed25519 key pairs printed under scratch-off zones. The sender reveals Zone A (private key) to sign, and the recipient reveals Zone B (public key) to verify. This prevents QR code cloning since copied codes lack matching physical keys. For additional protection, combine with tamper-evident packaging and holographic seals.

Key Management

Secure key management is critical for DSPIP shipping security. Organizations must protect shipping keys, last mile provider decryption keys, and split-key label manufacturing.

Private Key Protection

Shipping keys SHOULD use hardware security modules (HSM)
Last mile providers MUST secure decryption keys for recipient data
Split-key labels provide one-time-use keys (destroyed after signing)
Never store private keys in version control or unencrypted files
Implement access controls limiting who can use signing keys

Key Lifecycle Management

Use lifecycle fields: t (creation), exp (signing expiration), exp-v (verification expiration)
Recommended: Active signing period of 365 days, verify-only period of 365 days
Use seq (sequence number) for key updates - higher values supersede lower
Set s=verify-only when transitioning keys
Total recommended key lifetime: 730 days (2 years)

Key Rotation

Organizations SHOULD rotate keys annually (before exp timestamp)
MUST use different selectors for new keys with incremented seq
Old keys remain in DNS until exp-v for in-transit package verification
Emergency rotation procedures required for compromises
Test new keys before removing old ones from production

Key Revocation

Publish key revocation at _revoked-key._dspip.<domain>
Key revocation takes precedence over s=active in key record
Use short TTLs (60-300 seconds) for revocation records
Affected packages SHOULD be reissued with new labels
Maintain incident response procedures for key compromise

Record Signature (rsig)

Use rsig to cryptographically authenticate lifecycle metadata
Protects against DNS cache manipulation of t, exp, exp-v, s, seq fields
Same key signs both QR codes and rsig
For high-security deployments, use DNSSEC AND rsig together
Verifiers SHOULD reject records with failed rsig verification

Split-Key Label Manufacturing

Label producers for split-key authentication MUST follow secure manufacturing:

• Generate unique Ed25519 key pairs using HSM
• Use cryptographically secure random generation
• Print using secure facilities with tamper-evident scratch-off
• Destroy ALL digital copies after printing
• Never retain private keys
• Maintain audit log of serial numbers

Privacy Considerations

DSPIP's digital envelope model protects recipient privacy while maintaining package routability. Choose the appropriate privacy mode based on your security requirements.

📋 Standard Mode

Business shipments with transparency requirements
Full recipient info visible in payload
Traditional shipping workflow
Best for B2B or internal transfers

🔒 Encrypted Mode

Consumer privacy protection during transit
Recipient encrypted with ECIES + AES-256-GCM + HKDF-SHA256
Only last mile provider can decrypt address
Carrier notes and delivery instructions encrypted

🔐 Split-Key Mode

Maximum security for high-value shipments
Physical anti-cloning with Ed25519 keys
Offline verification (no DNS required)
One-time-use keys destroyed after signing

Correlation Prevention

Privacy modes include protections against tracking attacks:

🔍 Data Minimization

Random tracking IDs prevent correlation
Limited timestamp precision
Unique encryption per package
Organizations processing EU data MUST comply with GDPR

⛓️ Blockchain Privacy

Only hashed item IDs stored on-chain
Personal information MUST NOT be recorded
Confirmation hashes instead of raw data
Consider private chains for sensitive data

Offline Verification

For environments without network connectivity, DSPIP supports offline verification using cached DNS record bundles. This is useful for warehouse scanners, delivery vehicles, or remote locations.

Cache Bundle Format

{
  "version": "1.0",
  "generated": 1703548800,
  "expires": 1704153600,
  "records": {
    "warehouse._dspip.example.com": "v=DSPIP1; k=ec; ...",
    "emp-jsmith._dspip.example.com": "v=DSPIP1; k=ec; ..."
  },
  "signature": "<bundle_signature>"
}
      

Cache Requirements

Update frequency: Cache bundles MUST be updated at least weekly
Bundle signing: Bundles MUST be signed by organization's root key
Critical revocations: SHOULD use out-of-band distribution for urgent updates
Expiration: Scanners SHOULD warn when using expired bundles

Revocation Mechanisms

DSPIP provides two types of revocation: key revocation for compromised or retired signing keys, and item revocation for lost, stolen, or recalled packages.

Key Revocation

When a signing key is compromised, organizations publish key revocation records at a dedicated DNS endpoint that operates independently of key record caching for faster propagation.

_revoked-key._dspip.example.com. IN TXT "v=DSPIP1; type=key-revocation; selector=warehouse; revoked=1703548900; reason=compromised; replacement=warehouse-v2"

Revocation reasons: compromised, retired, superseded, suspended

Revocation List Format

{
  "version": "1.0",
  "issuer": "warehouse._dspip.example.com",
  "updated": 1703548800,
  "expires": 1719316800,  // 180 days auto-prune
  "revoked": [
    {
      "itemId": "TRACK-2025-000123",
      "revoked": 1703548900,
      "reason": "lost|stolen|damaged|recalled",
      "replacementId": "TRACK-2025-000124"
    }
  ],
  "signature": "issuer_signature"
}
      

Revocation Requirements

Distribution: Lists MUST be served over HTTPS
Auto-prune: SHIP entries expire after 180 days
Privacy option: Bloom filters may hide specific revoked items
Caching: Verifiers SHOULD cache lists based on TTL

DNS Revocation Pointer

revocation._dspip.example.com. IN TXT "v=DSPIP1; type=revocation; url=https://example.com/dspip/revoked.json; updated=1703548800; ttl=86400"

Operational Security

Beyond cryptographic protections, DSPIP requires operational security measures for shipping infrastructure.

Directory Services

HTTPS required: All key lookups and directory queries must use TLS
Authentication: Updates require proper authorization
Rate limiting: Prevent enumeration and abuse
Cache poisoning prevention: Validate DNS responses

Delivery Confirmation

Time-bounded challenges: Confirmation requests expire quickly
Location verification: GPS coordinates recorded with delivery
Multi-party attestation: High-value shipments require multiple signatures
Single-use delivery keys: Recipients may generate ephemeral keys

Security Reporting

If you discover a security vulnerability in the DSPIP protocol or reference implementation, please report it responsibly:

Email: security@dspip.io
Response time: We aim to acknowledge reports within 48 hours
Disclosure: We follow coordinated disclosure practices
Recognition: Security researchers will be credited (if desired)

Please include as much detail as possible: affected versions, reproduction steps, and potential impact assessment.