Side-channel vulnerability analysis and mitigations

[ghost]

Since Ferveo is intended to be an "online" protocol and some/many primitives being used are not constant-time/may have other side-channel vulnerabilities, there should be an analysis and potential mitigations investigated (as needed).

Fortunately Ferveo is not like TLS where the latency is highly important, so hopefully this should be straightforward.

[ggkitsas]

Starting a conversation, here are some initial thoughts:

Proposed methodology/flow (no strict order):

1. Define attack model
   • attacker profile(s)
   • environmental factors
2. Choose relevant side-channels (SC)
3. Locate Points of Interest (PoI)
4. Root cause analysis (RCA) (per PoI, per SC)
   • identify leakage component(s)
5. Assess acquisition quality (per PoI, per SC)
   • enough amount of traces available?
   • acquisition speed
   • SNR
   • resolution
6. Leakage assessment
7. Mitigation analysis (per PoI, per SC)
   • calculable effect?
   • attack resistant?
   • performance trade-off

Analysis

1. Attack model

   The following assumptions are (commonly) used:

   • full knowledge of target's implementation
   • full knowledge of target's software and hardware configuration (installed OS and libraries and their versions, hardware components, etc.)

2. Choose SC
   Characterizing different side-channel vulnerabilities based on a collection of factors (inspired by CVSS3.1):

   • Priviledges Required: the minimum priviledges (on the target) that the attacker needs
     • Values: None / Low (basic user) / High (admin,root)
   • Attack Vector: the logical proximity needed
     • Values: Physical / Local / Adjacent (i.e. same LAN with target) / Network (i.e. over internet)
   • Attack Complexity: Empirical, takes into account setup process, number of needed traces etc. It's a relative rather then absolute indicator
     • Values: Low / Medium / High / Very High
   • Scalability: How is attack effort affected by the number of targets in scope. It's a relative rather then absolute indicator
     • Values: Low / Medium / High

   These factors take a "base" value. Modified values can be derived from base ones when specific environmental factors are assummed.

   Environmental factors considered so far:

   • cohosting: allows other services to run on the same hardware with the target. For this analysis, cohosting can utilize any level of virtualization.
   • template: its feasible to use template attack for the given side-channel

   The following table lists SCs and their characterization. It is meant as a tool to help us decide which SC to consider. For the modified values, the relevant environmmental factor is in parenthesis.

	Vulnerability	Priviledges Required	Attack Vector	Attack Complexity	Scalability	Modified Priviledges Required	Modified Attack Vector	Modified Attack Complexity	Modified Scalability
1	Timing Analysis	None	Network	Low	High
2	Simple Power Analysis (SPA)	None	Physical	High	Low			Medium (template)
3	Differential/Correlation Power Analysis (DPA/CPA)	None	Physical	Very High	Low			High (template)
4	EM Analysis (EMA)	None	Physical	Very High	Low			High (template)
5	Fault Analysis (FA)	None	Physical	Very High	Low
6	SW-based Power Analysis	Low	Local	Medium	Low	None (cohosting)	Network (cohosting)		High (cohosting)
7	$\mu$-architectural (cache-timing, speculative)	Low	Local	High	Low	None (cohosting)	Network (cohosting)		High (cohosting)

3 & 4. PoI & RCA
Being thorough here; Start by considering all caclulations that includes a secret quantity and continue by removing the non vulnerable.

• [poi-tpke] shares in ${s_i*U, \ldots, s_{i+w_i}*U}$
  • knowing both ciphertext and plaintext, might give an edge (meet in the middle)
  • also partial control of ciphertext
  • if decryption shares are not send one by one then attacker has to deal with much higher search domain
  • wNAF can be used within each and across all multiplications. Increased dependance in wNAF leads to:
    • increased vulnearbility in cache based $\mu$-architectural
    • decreased vulnearbility to remote timing
• [poi-polyeval] share value during polynomial evaluation (dealer sharing)
  • unusual case - could FFT leak?
• [poi-k] symmetric $k$ in TPKEs $BLAKE2b(rQ)\oplus k$
  • $\oplus$ should be constant time; no timing or cache-based attacks should be possible here
  • target for DPA/CPA/EMA
    • ..but $r$ seems to act as a blind. Can it be deduced?

Could poi-tpke and poi-polyeval be combined?

5. Acquisition quality
   Define epoch as the period between key refresh.
   • poi-tpke
     • #traces: (number of decryptions per epoch)*validators
     • SNR: don't consider network jitter (due lateral movement, noise profiling etc.)
   • poi-polyeval
     • #traces: maximum is $n$ (number of participants)
   • poi-k
     • ephemeral per encryption?