Page 77 - Read Online

Page 70 Jiang et al. J Surveill Secur Saf 2020;1:61-78 I http://dx.doi.org/10.20517/jsss.2020.09

outsourced to the cloud, the user generates a warrant Λ which includes the pseudonym of A, the identity
hash value Q of attending physician B, and medical file information such as file type filetype, version
i
numberV , time stamp , etc. For example, Λ = P llQ llV llT llfiletype. Here, the N denotes the index of
T
A
N
B
N
N
N
different medical files. Then, the following is calculated:
→ (4)
( , ,ζΛ = 1 ζ ⋅⋅⋅  ) ← H 3 ()Λ
The patient A picks a random number t Λ ∈ Z q * , and generates an authorization:
R

δ Λ = (KAB ⋅ (ν 0 ∏ ν ⋅ ζ j ), g t Λ t ) (5)
Λ
j
= j 1
Finally, the patient A sends the warrant pair ( ,δΛ Λ ) = ( ,( , ))αβΛ to attending physician B. Then, the
attending physician B validates the warrant pair by calculating:
?  (6)
,
( ,)α e = ( e g g 1 ) (⋅ g 2 (K AB ),) (ν ⋅eH g e 0∏ ν ζ j , )β
2
j
= j 1
If the above equation is true, the attending physician B accepts the authorization δ ; otherwise, the patient
Λ
A fails to generate a valid warrant.
(2) AuthenticatorGen: Given a medical file F to be outsourced, the user first splits F into n blocks, and each
*
contains s sectors: F → {χ , ij n ×s , ij R * q ϑ ∈ Z , and for
} , where χ ∈ Z . For each file F, choose a random number t
R
q
the i-th block, yield a block authenticator as follows: s
s = KAB (H (Λ llFID lli) )σ = i i . (⋅KAB H 4 4 (Λ � ⋅ � FID i ∏ u χ j , ij ) ϑ t (7)
= j 1
*
(3) TagGen: A random name FID is chosen for a file from Z , and s random elements u ,,⋅⋅⋅ u ∈G. Set t

0
τ = Λ � FID ��n u 1 � ⋅⋅⋅ �u s � g Λ t t Λ � ϑ t q 0 AB 1 s
= Λ llFID lln llu ll ... llu llg llg g . Then, the user generates file tag t based on t and K to guarantee the
0
s
1
integrity of each distinct file information.
τ =
τ t = t 0 0 ll .�S Sign ()τ 0 K AB (8)
Hereafter, the user sends the file tag t to the TPA. Besides, KP = ( e H 2 (K AB ), )g can be pre-computed and
sent to TPA. In addition, the processed file F that comprises F , FID , Λ , δ , andσ is uploaded to the CS
*
i
Λ
and can be stored in the proposed stereo storage structure and removed from the user’s local side.
5.4 Integrity verification: Audit
The auditing procedure contains following three phases: Challenge, Response, and Verification. And the
process of integrity verification is shown in Figure 3.
(1) Challenge: First, the TPA confirms whether the file tag t of outsourced file can pass the verification by
retrieving t from the CS and performing .S Vrf ( ,τ K AB ). If the file tag t of outsourced file cannot pass the
0
verification, then the auditing task will not be executed, and the protocol aborts; otherwise, the TPA will
analyze t to acquire the total number n of outsourced file blocks. The TPA picks a random nonempty
0
*
subset ⊆I [1, ]n and a number of values s i ∈ Z at random, for each ∈i I. Then, the TPA distributes the
q
R
challenge set C = {( , ) }i s i ∈ iI and corresponding file identifier FID to the CS. After that, the TPA can compute
WP = e(H (Λ ll FID lli), ),WP = ( e H 4 4 (Λ � � FID i g t ϑ ∑ i ∈I i s in advance for the final verification.
)
(2) Response: CS locates to the corresponding file F in the stereo storage structure upon receiving a
*
s
challenge C and its file identifier FID from the TPA. Then, the CS computes χ j ∑ i ⋅ χ = , ij mod , ∈ qj [1, ]n
,
∈ iI
σ =
i s
andσ ∏ . After that, the CS sends to the TPA a proof P that consists of χ 1 , ,χσ and corresponding
s
i
authorizationδ .
∈ iI
Λ
(3) Verification: Once receiving the proof P, with public system parameter PP and file tag t, the TPA

first verifies the validity of δ by demonstrating the equation (6), and then, verifies aggregate block
Λ
authenticator as follows:
σ