Provably Secure Crossdomain Multifactor Authentication Protocol for Wearable Health Monitoring Systems

Wearable health monitoring systems (WHMSs) have become the most effective and practical solutions to provide users with lowcost, noninvasive, long-term continuous health monitoring. Authentication is one of the key means to ensure physiological information security and privacy. Although numerous authentication protocols have been proposed, few of them cater to crossdomain WHMSs. In this paper, we present an efficient and provably secure crossdomain multifactor authentication protocol for WHMSs. First, we propose a ticket-based authentication model for multidomain WHMSs. Specifically, a mobile device of one domain can request a ticket from the cloud server of another domain with which wearable devices are registered and remotely access the wearable devices with the ticket. Secondly, we propose a crossdomain three-factor authentication scheme based on the above model. Only a doctor who can present all three factors can request a legitimate ticket and use it to access the wearable devices. Finally, a comprehensive security analysis of the proposed scheme is carried out. In particular, we give a provable security analysis in the random oracle model. The comparisons of security and efficiency with the related schemes demonstrate that the proposed scheme is secure and practical.


Introduction
The advance in technologies such as sensing devices and wireless communication has propelled the wide application of Internet of things in the medical field [1][2][3]. One of the typical applications is wearable health monitoring systems (WHMSs), which is an effective and practical solution to provide users with ubiquitous, low-cost, noninvasive, long-term continuous health monitoring.
In the classic WHMS model [4], there are three types of participants in a single security domain, i.e., wearable device (WD), cloud server (CS), and mobile device (MD). Typically, various WDs, such as smart bracelets and smart shoes worn on users, can send the collected data to CS via the MD held by the users through Bluetooth, Wi-Fi, or other wireless networks [5]. The CS, as a trusted entity, is mainly in charge of device registration and private information storage. A MD (such as a smartphone) connected to the Internet can access the WDs with the aid of CS.
To achieve ubiquity, it is impractical to deploy a singledomain WHMS which includes all entities. In this paper, we mainly focus on multidomain WHMSs (see Figure 1). Without loss of generality, we suppose that there are two different domains, i.e., D1 and D2. The patient in domain D1 has a variety of WDs for collecting physiological data, while in another domain D2, the doctor monitors the patient through the MD and analyzes the patient's health data for medical treatment.
Although WHMSs bring great convenience to people, they also pose many security and privacy issues, such as sensitive personal information leakage and unauthorized access to device information [6]. Therefore, as one of the key means to fulfill data security and privacy protection [7], the authentication protocol is the focus of this paper.
To this end, numerous authentication protocols have been proposed in [8][9][10]. Most of them mainly concern a single domain where the wearable device collecting data and the mobile device accessing data held by the user are registered with the same server. However, in this paper, the two may be from two different domains. That is, few of them fit for multidomain WHMSs. Therefore, it is urgent to propose a multidomain authentication protocol for WHMSs.
1.1. Related Work. In order to resist malicious attacks on communication between wearable devices and smart devices, a number of authentication and key agreement (AKA) protocols for WHMSs have been put forward.
Kumar et al. [11] presented a two-factor authentication protocol based on a password and smart card (i.e., E-SAP), in which only symmetric key primitives are involved to achieve mutual authentication and key establishment. Li et al. [12] revealed that many previous schemes could not hide the user's identity information during the login session phase. Therefore, in order to protect the privacy of user identity, the dynamic identity-based AKA scheme was proposed. Amin et al. [13] designed a two-way AKA protocol for a medical monitoring system to realize the anonymity of medical staff. However, Jiang et al. [14] analyzed Amin et al.'s scheme [13] and pointed out that it could not prevent mobile device stealing attacks and sensor key exposure. Once a smart device is stolen or lost, it may lead to sensitive data leakage in the device. In order to mitigate the above situation, the biometric is introduced as the third authentication factor, resulting in a large number of three-factor authentication protocols [15][16][17][18].
In recent years, the rapid development of cloud technology has made it possible to transfer computation and storage burdens of wearable devices to cloud servers, which greatly reduces the computation cost of deploying WHMSs. To this end, cloud-assisted AKA protocols are proposed.
In 2016, the yoking proof-based AKA protocol was proposed in [19], which is applied to the deployment of wearable devices with the aid of cloud servers. Specifically, local authentication is performed between the mobile device and two wearable devices, while remote authentication is performed by a cloud server. In the same year, a new asymmetric three-party authentication scheme for mutual authentication between wearable devices and mobile devices was proposed in [20]. But in [21], it is pointed out that one of the hypotheses in [19] is impractical; that is, a long-term key shared between the mobile devices and the wearable device is required before the protocol starts. In addition, in terms of security, the scheme in [19] is not resilient to desynchronization attacks. Moreover, it is also revealed in [20] that an out-of-band channel is needed in the authentication phase of the scheme in [21], while in general, it is assumed that a secure channel is only needed in the registration phase.
In 2017, Wu et al. [20] provided a cloud server-assisted AKA scheme for the wearable computing, which realizes mutual authentication and anonymity for the wearable device. In their scheme, the cloud server can be considered a trusted entity. In 2018, Srinivas et al. [22] proposed a novel cloud server-centric authentication scheme for medical surveillance systems, in which the cloud server acts as a relay in the authentication procedure between the users and wearable sensor nodes. Most recently, a cloud-centric threefactor AKA protocol was proposed in [23], which unifies three biometric encryption methods.
In a multidomain scenario, smart devices located in one security domain want to access wearable devices in another domain. In this direction, a multigateway authentication scheme is proposed for a wireless sensor network in [24]. However, the scheme is prone to lost smart card attack since it does not involve public key cryptographic primitives.   Secondly, we propose a crossdomain three-factor authentication scheme based on the above model. Only a doctor who can present all three factors can request a legal ticket which can be used to access the wearable devices. Moreover, both Elliptical Curve Cryptography (ECC) and fuzzy verifier [26] are introduced to avoid lost smart card attacks, and the Elliptic Curve Diffie-Hellman (ECDH) is employed to fulfill the strong confidentiality of the protocol.
Finally, we present the security and performance analysis of the proposed scheme. The provable security analysis under the random oracle model is given. By comparing its security and efficiency with the related schemes, the security and practicability of the scheme are demonstrated.

1.3.
Organization of This Paper. The paper is organized as follows. In Section 2, we propose a crossdomain threefactor AKA scheme for WHMSs. The provable security analysis and informal security analysis are presented in Sections 3 and 4, respectively. Section 5 provides security analysis and efficiency comparison. The conclusion is given in Section 6.

The Proposed Protocol
In this paper, we are committed to a crossdomain scenario. Specifically, security domain D1 contains several WDs of a patient and the cloud server WCS, and security domain D2 contains the MD of a doctor and the cloud server MCS. The MD used by the doctor needs to access the WD that collects the patient's physiological data in the case of remote diagnosis [27].
We provide an authentication model for multidomain WHMSs (see Figure 2), which achieves mutual authentication and key agreement between WD and MD from two different domains [28]. The details are as follows. First, the MD sends an access request to the MCS to which it belongs. The MCS sends a ticket request to the WCS, and then, WCS responds to the MCS with the ticket, which contains the secret information associated with the WD. After obtaining the ticket forwarded to the MD through the MCS, the MD can use it to initiate an access request to the WD, and WD will send a response message after the authentication from WD. Finally, the WD and the MD achieves mutual authentication and also negotiates the session key for the future communication.
We present a crossdomain three-factor authentication protocol which includes 8 stages, i.e., (1) initialization phase, (2) wearable device registration phase, (3) mobile device registration phase, (4) login phase, (5) authentication phase, (6) session key agreement phase, (7) password and biometric update phase, and (8) dynamic smart device addition phase. The symbols and their descriptions in the scheme are shown in Table 1.

Initialization
Phase. At this stage, MCS m and WCS k preshare the key K CS m,k . Each fMCS m WCS k g pair has a shared key and can be identified based on each other's identity. A finite cyclic group G generated by a point P of a large prime n on the elliptic curve is selected by MCS m . It selects s as a private key, calculates the public key S = sP, and publishes it. WCS k stores its ID WCS k and the private key K WCS k in the database.

Wearable Device Registration
Phase. The holder of WD j performs the following steps (see Figure 3): (a) WD j issues the registration request to WCS k through the secure channel (b) When receiving the registration request, WCS k selects an identity ID WD j for WD j and calculates the shared key K WCS k −WD j = hðK WCS k kID WD j kRT WD j Þ. Then, WCS k stores fID WD j , K WCS k −WD j g in its database. Finally, the message <ID WD j , K WCS k −WD j > is sent by WCS k to WD j via the secure channel (c) WD j stores the parameters fID WD j , K WCS k −WD j g in its memory 2.3. Mobile Device Registration Phase. The holder of MD i (i.e., U i ) performs the following steps (see Figure 4): It continues to generate a random number b ∈ Ζ * n and then computes B = bP, C = bS = ðC x , C y Þ,

Authentication
Phase. At this stage, the mutual authentication between the participants is realized, as shown in Figure 5.
The password and biometric template of U i The generation and reproduction algorithm in a fuzzy extractor t The fault tolerance threshold used by Rep ⋅ ð Þ

RT
The registration timestamp The exclusive or ‖ The concatenation

A The adversary
Select an identity ID WD j

Wireless Communications and Mobile Computing
It continues to generate the current timestamp T 2 and determines which WCS k to be requested as well as the corresponding share key K CS m,k according to ID WD j ′ . Then, and sends <M 2 , WCS k obtains the responding key K WCS k −WD j according to ID WD j ′ , generates the current timestamp T 3 and a temporary key K WD j , and Session Key Agreement Phase. At this stage, a session key is established between MD i and WD j , as shown in Figure 6.   (1) First, add a new wearable device named WD new j . In essence, this process looks like the WD j initialization phase, so it just needs to register at WCS k :

Adversary Model.
We give the security model in this paper. It is assumed that the cryptographic primitives used are secure. That is, A is not capable of guessing the result of the hash functions, the random numbers, and the preshared keys of both parties used in the protocol.
Hypothesis 1. Communication channels are mainly divided into a private channel (i.e., a secure channel) and a public channel (i.e., an unsecure channel). For the public channel, we use the classic Dolev-Yao model [29], where an adversary can eavesdrop, intercept, delete, or modify any messages sent through the open channel. However, for a secure channel generally used in the registration phase, the adversary cannot obtain any information through this channel.
Hypothesis 2. According to [26], with the improvement of the attacker's ability, the privacy information in a smart card can be obtained by power analysis attacks or by exploiting software vulnerabilities. Therefore, we assume in this paper that an adversary can resolve the confidential information after obtaining the smart card.
Hypothesis 3. As the adversary model proposed in [26], the adversary A can offline exhaust all elements of the Cartesian product D id × D pw during the polynomial time, where D pw and D id denotes the password space and the identity space, respectively.

Wireless Communications and Mobile Computing
Hypothesis 4. As the security model of the three-factor AKA protocol proposed in [30], any two of three authentication factors can be obtained by A. However, it does not have the ability to obtain all authentication factors at the same time. The three cases are as follows:

Security Model.
We explain the security model used by the security proof in this section. There are four main participants in this paper: WD, WCS, MD, and MCS.
Generally, the adversary of the authentication protocol is a probabilistic polynomial time adversary, who can control the transmission channel, passively eavesdropping or actively modifying or delaying messages [31].
Participants. Let Π i U represent the ith session instance of the participant U, also known as the oracle.
Status. There are generally three states: accept, reject, and invalid. It is in the "accept" state when the oracle receives the correct message. It is in the "reject" state when the oracle receives the error message; when the output has no answer, we use ⊥ to indicate the invalid result.
Partnering. Instances of two participants can become partners of each other if and only if (1) both instances are in the "accept" state and have the same session key, (2) both instances share the same identity, (3) the ID of the former is the partner ID of the latter and vice versa, and (4) no other instance accepts the same session ID as both instances.
Freshness. An instance is said to be "fresh" if and only if (1) the attacker did not send a Reveal query to this instance or its partner instance and (2) the attacker did not corrupt the instance before the instance is in the accept state.
Adversary. The ability of the adversary can be simulated by the following queries to oracles: This query simulates passive eavesdropping attacks of A. For this query, the public-transmitted content of authentication instances executed between all participants will be obtained by A.
SendðΠ i U , mÞ. This oracle query simulates an active attack, and A sends the modified message to the instance Π i U on behalf of another party. After the instance Π i U receives the message, A will get a response message generated by the participant Π i U . Π i U can be a wearable device, a mobile device, and a cloud server in both domains.
RevealðΠ i U Þ. When the instance Π i U obtains a session key, the attacker has the ability to get the key. When an instance does not have a session key, the attacker gets an invalid flag ⊥.
CorruptðΠ i U Þ. Through this query, A can get secret credentials of corrupted participants, such as passwords, biometrics, and mobile devices. This query can simulate the forward security of the session key.
TestðΠ i U Þ. It can determine the security of the session key owned by the instance Π i U . After the simulator receives this query, it will perform a flip coin operation. When the result is 1, the attacker returns a real session key; when the result is 0, the attacker returns a random key string with the same length as the key. In this case, A must distinguish whether the returned value is a real session key or a random value, and the probability is 1/2.
We define the semantic security of the session key. A can only perform the Test query to fresh instances, and there are no restrictions on other queries. It is necessary for A to judge that the bit used by the simulator is 0 or 1 after the Test query. If it can guess the correct result, the attacker is considered to have succeeded in the semantic security of the protocol P and defined this successful event as Succ. The size of the dictionary space is jDj, and the advantage of the attacker to make this attack is defined as Adv ake P,D ðAÞ = 2 Pr ½Succ − 1. An authentication protocol is called semantically secure, if and only if for all probability polynomial time attackers, they have the advantage Adv ake P,D ðAÞ which is larger than kq send /jDj that can be ignored, where q send is the number of active attacks by A.

Security Proof
Theorem 1. Suppose that P is the proposed authentication protocol, E p is an elliptic curve group, and A is a PPT adversary. Adv ake P,D ðAÞ is the advantage for A to break the semantic security of the protocol P. A can execute at most q send send queries and q exe queries of different instances in the longest time t, so we have Proof. We use a series of mixed experiments Ex 0 , Ex 1 , Ex 2 , ⋯, Ex 7 to prove that the protocol is AKA secure. These experimental games start from a real attack scenario. Through continually changing some simulation rules in the experiments, we have the final experiment in which the attacker has little advantage in distinguishing between a session key and a random key of the same length. Let Adv i ðAÞ be the advantage of the attacker in Ex i and Δ i denote the degree of distinction between Ex i and Ex i+1 . Ex 0 . This is a scheme under the random oracle model. According to the definition of the advantage of the previous attacker, we have Ex 1 . In the hybrid experiment, we maintain a hash table H list to simulate all random oracles. When s is a string and wants to query HðsÞ, the oracle first searches the H list for the corresponding record fs, valueg. If found, the value corresponding to the record is returned. Conversely, the 8 Wireless Communications and Mobile Computing oracle produces a random bit string b ∈ f0, 1g l , returns the value to the interrogator, and stores the record fs, bg in the hash table. Since the random oracle is perfectly simulated in polynomial time, the attacker cannot distinguish Ex 0 from Ex 1 .
Ex 2 . In the previous experiment, we have known that the oracle is perfectly simulated in polynomial time, so we exclude relatively unlikely hash collisions. When a collision occurs in the passive session or oracle simulation, then we will end the simulation of the entire game and believe that the attacker has won the game. Based on a birthday paradox, we have Ex 3 . Simulation of the passive session has been changed in the experiment, considering the probability that the attacker would not make any random oracle query but can forge the authentication information <M 1 , M 2 , M 4 , M 5 , M 6 , M 7 > . Ex 2 and Ex 3 are indistinguishable from A unless they provide valid information to end the game. Specifically, for the authentication message the case that no corruption request is made, σ i ′, PW i cannot be obtained or the key K MD i is unknown to the attacker, and the valid information M 1 cannot be calculated, so the attacker has a negligible probability of success. So Ex 4 . Simulation of the active session has been changed in the experiment. For a SendðMCS m , ðB, M 1 ÞÞ query, if A does not corrupt the MD, while M 1 is the valid verification message generated by A, then we only need to let A achieve the final victory of the game and stop the simulation game. If such events occur, the attacker can get the random number b when knowing B, P and generate the random number C, in which B = bP, b ∈ Ζ * n , and C = bS = ðC x , C y Þ and the message M 1 contains C x . The probability of successful construction of the message M 1 described above is equal to the probability of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP) in ECC. The ECDLP is a difficult problem in cryptography, so the probability of an attacker's success is negligible. In short, we have Ex 5 . We continue to change the simulation of the active sessions during the experiment. If the attacker sends a Reveal ðWCS k Þ query to the WCS, it will get the session key SK CS m,k = hðK CS m,k kT 2 kT 3 Þ between the WCS and the MCS and can also calculate the temporary key K WD j . However, in order to generate valid verification information M 4 , A needs to gener-ate a valid Ticket WD j . It is able for A to know the identity of Ticket WD j and specify the lifetime according to the general rules, but A cannot get the key shared by WCS and WD in advance. If A can guess and get a valid Ticket WD j , we terminate the simulation of the game and declare that the attacker has already won the game. The probability of such an event is negligible, so there will be Ex 6 . We change the simulation rules of the activity sessions again in the experiment. Specifically, for message M 5 , assume that A previously obtained the value of S and B by eavesdropping, where B = bP, the random number b ∈ Ζ * n , but the probability of successfully forging bsP of the message M 5 is actually equivalent to the probability of solving the Elliptical Curve Computational Diffie-Hellman Problem (ECCDHP). It is well known that ECCDHP is a difficult problem in cryptography, so the success probability of an attacker is negligible, so there are Ex 7 . Finally, we change the simulation of the activity sessions in the experiment. During the session key agreement phase, an attacker may have previously obtained Ticket WD j by eavesdropping. If A fakes the message <Ticket WD j , T 5 , M 6 , B > and sends it to WD j , then we just need to let A win and terminate the simulation. However, it should be noted that K WD j is an unknown security parameter, so the probability that A can effectively generate this information is negligible. Based on the above, we have In the final experiment, there is no real password-related information in the session using the Execute query from A, so there is no advantage, and the active attack through the Send query is only

Informal Security Analysis
This section shows that our scheme can achieve many security attributes.

Preventing Stolen Mobile Device Attack.
If A has got a stolen or lost MD i , it can get the information fGenð⋅Þ, Repð⋅Þ, τ i , hð⋅Þ, e i , f i , lg stored in MD i . First, the adversary A wants to correctly guess the doctor's password PW i and needs to guess the password and verify the security parameters e i = h ðhðID i kPW i kσ i ′Þ mod lÞ. According to the assumptions about the ability of the adversary given in this paper, A can get both identity ID i and biometric BIO i , but e i is a fuzzy verifier ð2 4 < l < 2 8 Þ, so there are jD id j/l possible password 9 Wireless Communications and Mobile Computing alternatives. To get the only correct password, A has to identify it online, and this can be prevented by implementing a number-limiting strategy. On the other hand, A may also try to get a unique correct password by f i = TC i ⊕ hðID i kσ i kPW i Þ. However, TC i = hðID i kK MD i kRT MD i Þ, and it is protected by the key K MD i , which is generated by MCS m for MD i . So, this method cannot be implemented. Therefore, it is found that the above two possible attack methods are not feasible; that is, our protocol can prevent such attack.

Preventing Replay Attack. Suppose that
and <T 6 , M 7 , D > in the login phase, the authentication phase, and the session key negotiation phase. Then, A replays them on the public channel, but it is intuitive to see that all of the messages we transmit contain the timestamp, which is the time when the message is sent. We use timestamps and random nonce in the protocol to guarantee the freshness of the transmitted information. If there is an adversary attempting to repeatedly send these messages, the existence of this situation will be found by verifying the validity of the timestamp. In addition, it is not feasible for an adversary to bypass the message recipient's verification of the timestamp because all messages contain a key-protected hash value. Therefore, our protocol can prevent replay attacks.

Preventing Man-in-the-Middle Attack. It is assumed that
A is able to intercept the sent messages in the login phase, authentication phase, and key agreement phase and replace those messages with its own messages to perform the attack as a middleman.
Specifically, if A wants to modify the message <PID i , PID WD j , T 1 , M 1 , B > and the key to the parameter M 1 , B is to generate a random number b ∈ Ζ * n , A can randomly select b ∈ Ζ * n and calculate B = bP, C = bS = ðC x , C y Þ, PID i = ID i ⊕ C x , PID WD j = ID WD j ⊕ C y , and M 1 = hðID i kID WD j kTC i ′ kT 1 k C x Þ. The message receiver will confirm whether the party is a legitimate one by verifying M 1 = M 1 ′. Both of the messages TC i = f i ⊕ hðID i kσ i kPW i Þ and TC i = hðID i kK MD i kRT MD i Þ of M 1 are protected by a password or a key K MD i , so A cannot calculate TC i . It can be seen that A cannot replace the real message M 1 with his fake message and gain the trust of the receiver as an intermediary. For the message <M 2 , M 3 , T 2 , ID MCS m > sent from MCS m to WCS k , A intercepts the message as an intermediary and replaces it with its own messages. It wants to pass the verification of WCS k and then needs to send the correct <M 2 , M 3 > . To calculate M 2 = hðK CS m,k kI If not, the login request is rejected. Therefore, our protocol can detect unauthorized login by user doctor's error input or intentional attack by the attacker during the login phase.

Anonymity and Untraceability.
We assume that A intercepts all information <PID i , PID WD j , T 1 , M 1 , B > , <M 2 , M 3 , T 2 , ID MCS m > , <Ticket WD j , TK WD j , T 3 , M 4 > , <Ticket WD j , TTK WD j , T 4 , M 5 , C > , <Ticket WD j , T 5 , M 6 , B > , and <T 6 , M 7 , D > transmitted on the public channel during the login phase, the authentication phase, and the session key negotiation phase.
It can be seen from all messages that they contain timestamps or nonces and are protected by their own keys or shared keys, thus ensuring confidentiality. Only when A knows these secret parameters can A obtain the identity information related to U i , MD i , and WD j . Therefore, our protocol achieves anonymity [32,33]. On the other hand, we can also find that these messages are dynamic. The pseudoidentity PID i of users is different in each session, and b ∈ Ζ * n is randomly selected. Therefore, the message fields in each session are different, and the adversary cannot obtain useful information through different sessions, so untraceability is realized.

Known Key Security.
It is assumed that the adversary A has obtained the session key SK MD i −WD j = hðID i kID WD j kT 6 kT 5 kK WD j kbdPÞ shared by MD i and WD j . However, because our protocol uses timestamps and each session includes a randomly chosen temporary key K WD j to guarantee that the session key of the current session is totally different from the previous session key, our protocol accomplishes known key security.
4.8. Perfect Forward Secrecy. In our scheme, U i has long-term secrets PW i , BIO i , and e i = hðhðID i kPW i kσ i ′ Þ mod lÞ, and when the long-term secrets of U i are leaked, the previous session key SK MD i −WD j = hðID i kID WD j kT 6 kT 5 kK WD j kbdPÞ will not be leaked. Because b and d are randomly selected, it is difficult to calculate bdP by bP and dP according to ECCDHP.
4.9. Extensibility. The protocol includes a mobile device or wearable device dynamic addition phase, so it can provide extensibility. Through this phase, we are able to dynamically add mobile devices or wearable devices, which only need to interact with the cloud servers of the security domain to which they belong. The cloud server maintains a table. Therefore, the protocol can provide the security features of extensibility.

Efficient Password and Biometric
Update. Because of the efficient detection mechanism of unauthorized logins, doc-tors can freely update passwords or biometrics in our protocol, as shown in Section 2.7.

Security and Efficiency Comparison
5.1. Security Comparison. The security comparison of our scheme with [34,35] is shown in Table 2. Table 2 shows that the schemes in [34,35] fail to meet all the security features listed in the table, such as inability to defend against MD stolen attacks. Our scheme can satisfy a number of security features, which has been proven in previous security analysis.

Efficiency Comparison.
For efficiency, we mainly pay attention to the login, authentication, and session key agreement phases. The following symbols are used to define various calculations as well as their specific time consumption.
T s : the time complexity of symmetric encryption and decryption (0.0214385 ms) [35].
T p : the time complexity of point multiplication operation of an elliptic curve (0.427576 ms) [35].
T h : the time complexity of computing hash functions (0.0000328 ms) [35].
The efficiency comparison of our scheme with [34,35] is shown in Table 3.
Our scheme has two cloud servers, and each domain has one cloud server. Different from our scheme in the number of participants, there is only one cloud server in schemes [34,35]. Since the cloud server has stronger computing power and more resource [36], we only pay attention to the calculation of time consumption of mobile devices and

Schemes
The scheme in [34] The scheme in [35] Our scheme

Schemes
Our scheme The scheme in [34] The scheme in [35] MD