보안 프로토콜들이 정의되어지는 방법은 여러가지가 있지만, Tamarin에서는 미리 정의된 프로토콜 컨셉이 없다. 사용자가 자유롭게 모델링하면 된다.

Public-key infrastructure

Tamarin 모델에서, PKI(public key infrastructure)의 미리 정의된 노테이션은 없다. 각 party를 위해서 비대칭키를 사용한 미리 분배된 PKI(A pre-distributed PKI with asymmetric keys)는 party를 위해 키를 생성하는 단일 규칙에 의해서 모델링 될 수 있다. Party의 identity와 public/private key들은 fact들로써 저장될 수 있다. public key를 위해서, 우리는 흔히 Pk fact를 사용하고, 해당 public key에 대응되는 long-term private key를 위해 Ltk fact를 사용한다. 이러한 fact들이 오직 key를 얻기 위한 다른 rule들에 의해서 사용될 것이기 때문에, 우리는 persistent fact로 모델링 한다. 우리는 private key x에 대응하는 public key를 나타내기 위해서 추상 함수(abstrat function) pk(x)를 사용한다.

rule Generate_key_pair:
    [ Fr(~x) ]
    -->
    [ !Pk($A, pk(~x))
    , Out(pk(~x))
    , !Ltk($A, ~x)
    ]

Naxos와 같은 몇몇 프로토콜들은 키 쌍의 대수 성질(the algebraic properties)을 사용한다. 많은 DH기반의 프로토콜들에서, private key $x$에 대한 public key는 $g^x$ 로 표현한다. 이 것을 다음과 같은 rule로 표현할 수 있다.

rule Generate_DH_key_pair:
    [ Fr(~x) ]
    -->
    [ !Pk($A, 'g'^~x)
    , Out('g'^~x)
    , !Ltk($A, ~x)
    ]

Modeling a protocol step

프로토콜들은 시스템에서 에이전트들의 행동을 나타낸다. 에이전트들은 메시지를 받고 응답을 보내거나 세션을 시작하는 등의 프로토콜 단계(a protocol step)을 수행할 수 있다.

Modeling the Naxos responder role

우리가 responder role을 만들 때, 한 rule내에서 완료되기 때문에 initiator role보다 간편하다. Diffie-Hellman 지수연산과 두 해시 함수 h1, h2를 사용하는 프로토콜을 설계하려면 반드시 다음과 같이 선언해야 한다.

builtins: diffie-hellman

functions: h1/1
functions: h2/2

추가적인 equations없이는, 해당 방법으로 선언한 function들은 one-way function이다.

각각의 responder 스레드(Thread)는 에이전트$R이 메시지를 수신할 때마다, responder는 새로운 값 ~eskR을 생성하고, 응답 메시지를 전송하며, key kR을 계산할 것이다. 우리는 rule의 LHS에 In fact를 지정함으로써 메시지를 수신하는 모델을 설계할 수 있다. 새로운 값을 생성하는 과정은 내장된 fresh rule(Fr)을 사용하여 생성되도록 요구된다.

결국, 이 규칙은 행위자의 long-term private key에 따라 결정되며, 이는 이전에 제시된 Generate_DH_key_pair rule에 의해 생성된 persistent fact에서 얻을 수 있다.

응답 메시지는 기존 해시 함수의 거듭제곱을 사용하여 g를 지수화한 값이다. 해시 함수가 단항 함수(unary, arity one)이므로, 두 개의 메시지를 연결한 값을 인자로 사용하려면 <x, y> 형태의 쌍(pair)으로 모델링하여 단일 인자로 h1을 호출해야 한다.

이 규칙의 초기 공식화는 다음과 같다.

rule NaxosR_attempt1:
    [ 
      In(X),
      Fr(~eskR),
      !Ltk($R, lkR)
    ]
    -->
    [
      Out('g'^h1(<~eskR, lkR>))
    ]

하지만, responder는 또한 session key kR을 계산한다. session key가 메시지의 송수신에 영향을 주지 않기 때문에, 우리는 rule의 LHS와 RHS으로부터 제외할 수 있다. 그러나 이후 보안 속성(security property)에서 session key에 대한 주장을 제시해야 한다. 따라서, 계산된 key를 action에 추가한다.

rule NaxosR_attempt2:
    [
      In(X),
      Fr(~eskR),
      !Ltk($R, lkR)
    ]
    --[ SessionKey($R, kR) ]->
    [
      Out('g'^h1(<~eskR, lkR>))
    ]

kR의 계산은 위에서 아직 정의되어 있지 않다. 우리는 kR을 완전히 전개하여 명시할 수 있지만, 가독성이 떨어지므로 let ... binding을 사용하여 중복을 방지하고 불일치(mismatches) 가능성을 줄인다. 게다가, key 계산을 위해서 우리는 통신 파트너 $I의 public key가 필요하다. $I는 ~tid라는 thread identifier로 바인드 되어있다.

rule NaxosR_attempt3:
    let
        exR = h1(<~eskR, lkR>)
        hkr = 'g'^exR
        kR = h2(<pkI^exR, X^lkR, X^exR, $I, $R)
    in
    [
        In(X),
        Fr(~eskR),
        Fr(~tid),
        !Ltk($R, lkR),
        !Pk($I, pkI)
    ]
    --[ SessionKey(~tid, $R, $I, kR) ]->
    [
        Out(hkr)
    ]

위의 모델은 responder의 역할을 정확하게 수행한다.

우리는 Tamarin의 역방향 탐색(backwards search)을 최적화할 수 있는 추가적인 방법을 고려할 수 있다. NaxosR_attempt3에서 규칙은 lkR이 임의의 항(term)으로 인스턴스화 될 수 있도록 지정하고 있으며, 이로 인해 새롭게 생성되지 않은(non-fresh)항도 허용될 가능성이 있다.

그러나, 키 생성 규칙은 Ltk fact를 생성하는 유일한 규칙이며, 이 규칙은 항상 새롭게 생성된(fresh)값을 사용하여 키를 생성한다. 따라서, 시스템의 어떠한 도달 가능한 상태에서도 lkR은 반드시 fresh 값으로만 인스턴스화됨이 보장된다.

이를 바탕으로 우리는 lkR을 sort fresh로 명시적으로 선언할 수 있으며, 이를 통해 lkR을 ~lkR로 대체할 수 있다. 이러한 변경을 통해 Tamarin의 역방향 탐색이 더욱 효율적으로 수행될 수 있다.

rule NaxosR_attempt3:
    let
        exR = h1(<~eskR, ~lkR>)
        hkr = 'g'^exR
        kR = h2(<pkI^exR, X^~lkR, X^exR, $I, $R)
    in
    [
        In(X),
        Fr(~eskR),
        Fr(~tid),
        !Ltk($R, ~lkR),
        !Pk($I, pkI)
    ]
    --[ SessionKey(~tid, $R, $I, kR) ]->
    [
        Out(hkr)
    ]

Modeling the Naxos initiator role

Naxos 프로토콜에서 Initiator 역할은 메시지를 전송하고 응답을 기다리는 과정으로 구성된다. 그러나 initiator가 응답을 기다리는 동안, 다른 에이전트들도 동시에 동작할 수 있다. 따라서, initiator 역할을 두 개의 규칙으로 모델링한다.

첫 번째 규칙은 initiator 역할을 시작하고, 새로운 값을 생성하고, 적절한 메시지를 전송하는 것을 모델링한다. 앞선 예시와 마찬가지로 let ... in 바인딩을 사용하여 표현을 단순화하며, !Ltk fact는 항상 새로운 값을 두 번째 인자로 사용하여 생성되므로, lkI대신 ~lkI를 사용한다.

 rule NaxosI_1_attempt1:
      let exI = h1(<~eskI, ~lkI >)
          hkI = 'g'^exI
      in
       [   Fr( ~eskI ),
           !Ltk( $I, ~lkI ) ]
       -->
       [   Out( hkI ) ]

Using state facts to model progress

이전 규칙이 트리거된 후, initiactor는 응답을 기다리게 된다. 우리는 아직 두 번째 부분을 모델링해야 하며, 이는 응답을 수신하고 키를 계산하는 과정이다. Initiator 규칙의 두 번째 부분을 모델링하려면, 첫 번째 부분이 특정한 매개변수와 함께 수행되었음을 명확하게 지정할 수 있어야 한다. 직관적으로 보면, 전이 시스템의 상태에 특정 initiator thread가 특정 매개변수를 사용하여 첫 번째 메시지를 보냈다는 사실을 저장해야 한다.

이를 모델링하기 위해 새로운 fact를 도입하는데, 이를 state fact라고 부른다. 이는 특정 프로세스 또는 thread가 실행의 어느 지점에 있는지를 나타내며, 실질적으로 프로그램 카운터 역할을 하면서 해당 프로세스나 메모리 내용을 저장하는 컨테이너 역할도 수행한다. 또한, 동시에 여러 Initiator가 실행될 수 있으므로, 각 initiator의 state fact에 대해 고유한 handle을 제공해야 한다.

아래는 initiator의 첫 번째 규칙을 업데이트한 버전으로, 새로운 state fact인 Init_1을 생성하며, 각 규칙의 인스턴스마다 고유한 thread identifier ~tid를 도입한다.

rule NaxosI_1:
  let exI = h1(<~eskI, ~lkI >)
      hkI = 'g'^exI
  in
   [   Fr( ~eskI ),
       Fr( ~tid ),
       !Ltk( $I, ~lkI ) ]
   -->
   [   Init_1( ~tid, $I, $R, ~lkI, ~eskI ),
       Out( hkI ) ]

state fact는 여러 개의 매개변수를 가진다는 점에 주목해야 한다.

rule NaxosI_2:
  let
      exI = h1(< ~eskI, ~lkI >)
      kI  = h2(< Y^~lkI, pkR^exI, Y^exI, $I, $R >)
  in
   [   Init_1( ~tid, $I, $R, ~lkI , ~eskI),
       !Pk( $R, pkR ),
       In( Y ) ]
   --[ SessionKey( ~tid, $I, $R, kI ) ]->
  []

두 번째 규칙에서는 네트워크에서 메시지 Y를 수신해야 하며, 이전에 initiator fact가 생성되었음도 요구된다. 이 규칙은 해당 fact를 소모(consume)하며, 프로토콜에서 더 이상의 단계가 없으므로, 유사한 fact를 출력할 필요가 없다. 또한 Init_1 fact가 동일한 매개변수로 인스턴스화되었기 때문에, 두 번째 단계에서는 첫 번째 단계에서 계산된 동일한 에이전트 ID 및 지수 exI를 사용하게 된다.

Clustering by Role

그래프의 명확성을 높이고 역할을 식별하기 위해, 노드들을 해당 역할에 따라 클러스터로 그룹화할 수 있다. 클러스터는 단순히 표시 방식에 관한 것이며, Tamarin의 추론에는 영향을 미치지 않는다. 이러한 클러스터링의 목적은 그래프를 더 쉽게 읽을 수 있도록 하는 것이며, 사용자가 이를 활성화하거나 비활성화할 수 있다. 클러스터는 관련된 노드를 포함하는 색상 박스로 표시된다.

클러스터링은 동일한 역할의 서로 다른 세션을 별도의 클러스터로 분할한다. 이를 위해 다음과 같은 휴리스틱을 사용한다. 같은 역할의 두 노드는 linear fact의 사용으로 인해 생성된 edge로 연결된 경우에만 같은 클러스터로 묶인다. 클러스터 내의 규칙들은 클러스터의 색상과 동일한 색을 가진다.

역할에 의해 그룹화하는 2가지 방법이 존재한다.

Manual Clustering

사용자는 특정 역할(role)의 동작을 나타내는 규칙을 수동으로 지정할 수 있다. 이를 위해, 해당 규칙에 역할의 이름을 다음과 같이 주석(annotation)으로 추가할 수 있다.

rule test[role="Alice"]:
   [...]
   -->
   [...]

Automatic Clustering

설정 옵션 중 Clusterling By Role이라는 기능이 제공되며, 이를 활성화하면 자동으로 역할별 정렬이 수행된다. 이 옵션은 기본적으로 비활성화 되어 있다. 이 기능을 사용하면 이름이 유사한 모든 규칙이 자동으로 클러스터로 그룹화되며, 이는 수동 클러스터링보다 우선적으로 적용된다. 예를 들어, Alice_1, Alice_2, Alice_test_1, Bob_1이라는 규칙이 있을 경우, 이는 자동으로 세 개의 클러스터(Alice, Alice_test, Bob)으로 분리된다.

Tamarin 모델들은 3가지 주요 성분을 가지고 제작한다.

• Rules
• Facts
• Terms

우리는 이미 이전 섹션에서 해당 용어들에 대한 정의를 보았다. 이제 Naxos protocol을 통해 facts와 rules의 사용법을 알아보자.

출처 : https://tamarin-prover.com/manual/master/book/005_protocol-specification-rules.html

해당 프로토콜에서는, 각 참여자 x는 long-term private key인 lkx와 이에 대응하는 public key pkx = 'g'^lkx를 가지고 있다. (g는 Diffie-Hellman 그룹의 generator를 의미한다) g의 값이 공개 값이기 때문에, 우리는 이것을 공개 상수로써 모델링 한다. 여기서는 두 개의 서로 다른 해시 함수 h1과 h2가 사용되었다.

위 그림의 프로토콜은 다음과 같이 나타낼 수 있다.

1. initiator I는 새로운 nonce eskI를 생성한다. (eskI는 I's ephemeral (private) key를 의미한다)
2. I의 long-term private key lkI와 eskI를 concatenate한 후, 해시 함수 h1을 이용하여 'g'^h1(eskI, lkI)를 responder R에게 전송한다.
3. R은 전달 받은 값을 변수 X에 저장하고, R이 선택한 nonce인 eskR과 long-term private key lkR을 기반으로 생성한 'g'^h1(eskR, lkR)을 I에게 전송한다.
4. I는 전송받은 값을 변수 Y에 저장한다.

두 참가자는 각자의 long-term private keysession key kI와 kR을 각각 계산할 수 있게 된다.

교환된 메시지들은 수신자들이 메시지 생성에 사용된 long-term key를 검증할 수 없기 때문에 인증되지는 않는다. 인증은 암묵적이고 오직 정당한 키의 소유권을 통해서만 보장된다. 명시적인 인증(e.g. 의도된 상대방이 최근까지 활성 상태였거나 특정 값에 대해 합의했다는 보장)은 key-confirmation 단계(각 참가자들이 계산된 세션 키를 통해 생성된 교환된 메시지의 MAC을 교환하는 과정)를 추가함으로써 인증된 키 교환 프로토콜(AKE protocol, Authenticated Key Exchange protocol)에서 수행된다.

참고 Naxos 프로토콜의 자세한 내용은 다음 자료를 참고해라. LaMacchia, B., Lauter, K., & Mityagin, A. (2007, November). Stronger security of authenticated key exchange. In International conference on provable security (pp. 1-16). Berlin, Heidelberg: Springer Berlin Heidelberg.

Rules

우리는 프로토콜과 공격자의 동시 실행을 명시하기 위해 멀티셋 재작성(multiset rewriting)을 사용한다. (공격자가 프로토콜을 수행하는 참여자들과 병렬로(=동시에) 상호작용하는 상황을 다루겠다는 의미로써, 공격자는 eavesdropping, modification, forgery, replay 할 수 있는 능력을 가진다) 멀티셋 재작성은 독립적인 전이를 지원하기 때문에 동시 시스템을 모델링하는 데 일반적으로 사용된다.

멀티셋 재작성 시스템은 전이 시스템을 정의하며, 우리의 경우 전이는 라벨이 지정된다. 이 시스템의 상태는 fact의 멀티셋(또는 bag)으로 표현된다.

Tamarin에서 재삭성 규칙은 이름과 세 part를 가진다. 각각, rule의 LHS, 라벨이 지정된 전이(action fact라 부른다), rule의 RHS

rule MyRule1:
    [ ] --[ L('x') ]-> [ F('1', 'x'), F('2', 'y') ]

rule MyRule2:
    [ F(u,v) ] --[ M(u,v) ]-> [ H(u), G(`3`, h(v)) ]

rule의 이름은 중복되지 않는 한, 임의로 정할 수 있다.(이름에는 어떠한 의미도 없다)

Executions

전이 시스템의 초기 상태는 빈 멀티셋이다. 규칙들은 시스템이 새로운 상태로 전이를 만들 수 있는지 정의한다. 어떤 규칙이 현재 상태에 적용될 수 있으려면, 해당 규칙의 LHS가 현재 상태를 포함될 수 있도록 인스턴스화(instantiation)할 수 있어야 한다. 이 경우에, LHS 사실(facts)들은 현재 상태에서 사라지고 인스턴스화된 RHS의 fact로 교체된다.

예를 들어서, 초기 상태에서 MyRule1이 반복적으로 인스턴스화 되어질 수 있다.

어떤 방식으로든 MyRule1의 인스턴스화는 후속 상태가 F('1', 'x'), F('2', 'y')를 포함하는 것을 야기한다. MyRule2 규칙은 초기 상태가 F 사실을 포함하고 있지 않기 때문에 초기 상태에서는 적용될 수 없다. successor state(MyRule1이 적용된 후의 상태(후속 상태))에서는 MyRule2가 두 번 적용될 수 있다.

• u = '1', v = 'x'로 인스턴스화 될 수 있음.
• u = '2', v = 'y'로 인스턴스화 될 수 있음. 이러한 각 인스턴스화는 새로운 후속 상태(successor state)로 이어지게 된다.

Using 'let' binding in rules for local macros

더 복잡한 프로토콜을 모델링할 때, 한 용어(term)는 같은 rule에서 여러번 나타날 수 있다. 이러한 명세들의 가독성을 높이기 위해서, Tamarin은 let ... in 키워드를 지원한다.

rule MyRuleName:
    let foo1 = h(bar)
        foo2 = <'bars', foo1>
        ...
        var5 = pk(~x)
    in
    [ ... ] --[ ... ]-> [ ... ]

이러한 let-binding 표현식은 규칙의 문맥 내에서 로컬 term 매크로를 지정하는 데 사용할 수 있다. 각 매크로는 별도의 줄에서 정의되어야 하며, substitution을 의미한다( LHS는 반드시 변수이어야 하고, RHS는 임의의 항(term)이 될 수 있다) 규칙은 let-binding에서 정의된 변수를 모두 해당 RHS의 값으로 치환된 후 해석된다. 또한, 위의 예제에서 볼 수 있듯이, 매크로는 앞서 정의된 매크로의 좌변 값을 사용할 수도 있다.

Global macros

때때로 우리는 여러 rules에서 동일한 let-binding(s)을 사용하길 원한다. 이 경우에는, macros 키워드를 사용하여 global macros로 선언할 수 있다. 이 전역 매크로는 모든 rules에서 사용가능하다.

macros: macro1(x) = h(x), macro2(x, y) = <x, y>, ... , macro7() = $A

여기서 macro1은 첫 번째 매크로의 이름이며, x는 해당 매크로의 매개변수이다. = 기호의 오른쪽에 있는 항(term)은 매크로의 출력이며, 해당 매크로가 반환하는 값이다 규칙(rule)에서 매크로를 사용하려면, 해당 매크로를 함수처럼 항 내부에서 호출하면 된다.

[ In(macro1(~ltk)) ] --[ ... ]-> [ Out(macro2(pkA, pkB)) ]

위 예제는 매크로가 적용되고 나면 다음과 같이 바뀌게 될 것이다.

[ In(h(~ltk)) ] --[ ... ]-> [ Out(<pkA, pkB>) ]

후속 매크로가 먼저 정의 되어 있다면, 매크로는 후속 매크로(second macro)를 호출할 수 있다

macros: innerMacro(x, y) = <x, y>, hashMacro(x, y) = h(innerMacro(x, y))

밑의 예시는 에러이다.

macros: hashMacro(x, y) = h(innerMacro(x, y)), innerMacro(x, y) = <x, y>

hashMacro가 정의되었을 때, innerMacro가 아직 정의되어지지 않았기 때문이다.

매크로는 규칙(rule)에만 적용되며, Interactive mode에서 프로토콜 규칙과 함께 표시된다.

Facts

Tamarin에서 Fact는 프로토콜 실행의 상태를 나타내는 요소이다. Fact는 고정된 arity(매개변수 개수)를 가지며, 형식은 다음과 같다. $$ F(t_1, ..., t_n) $$

• F는 Fact의 이름(심볼)이며, t는 해당 fact에 포함된 변수 또는 값이다.

Tamarin에는 내장된 특수한 Fact 3가지가 존재한다.

1) In()

• 신뢰할 수 없는 네트워크에서 메시지를 받는 것을 의미
• 공격자가 제어하는 네트워크에서 메시지를 수신하는 상황을 모델링
• 재작성 규칙의 LHS에서만 사용 가능

2) Out()

• 신뢰할 수 없는 네트워크로 메시지를 보내는 것을 의미
• 공격자가 접근할 수 있는 채널을 통해 메시지가 전송됨
• 재작성 규칙의 RHS에서만 사용 가능

3) Fr()

• 고유한 난수(fresh value)를 생성하는 역할
• 재작성 규칙의 LHS에서만 사용 가능
• Tamarin의 내장 규칙에 의해서 Fr(x)는 항상 다른 새로운 값을 생성

Linear versus persistent facts

위에서 언급한 사실(facts)들은 '선형 사실(linear facts)'라고 불린다. 이들은 규칙에 의해 생성될 뿐만 아니라, 규칙에 의해 소멸될 수도 있다. 따라서, 특정 상태에서는 존재할 수 있지만 다른 상태에서는 사라질 수도 있다.

반면, 일부 사실은 한 번 도입되면 절대로 상태에서 사라지지 않는다. 이러한 사실을 선형 사실을 사용하여 모델링하려면, 해당 사실이 LHS에 포함된 모든 규칙에서 동일한 사실을 RHS에도 복사해야 한다. 이론적으로는 문제가 없지만, 사용자에게 불편할 수 있으며, Tamarin이 해당 사실을 추적하는 데 불필요한 규칙 인스턴스화를 탐색할 수도 있다.

지속적 사실(persistent facts)는 fact이름 앞에 ! 키워드를 붙여 선언한다. 절대 소멸되지 않는 사실을 모델링할 때는 지속적 사실을 사용하는 것이 선호된다.

Tamarin은 암호학(Cryptography)의 기호적 모델(symbolic model)을 사용하여 프로토콜을 분석한다. 즉, 암호화된 메시지를 비트 문자열(bit string)로 다루는 것이 아니라, 수학적 항(term)으로 모델링한다. 사용된 암호 알고리즘의 속성은 방정식(equation)으로 모델링된다. 더 구체적으로, 암호 메시지는 다음 중 하나이다.

• 상수 C
• f(m1, ..., mn) 형태의 메시지: 이는 n개의 암호 메시지 m1, ..., mn에 n항 함수 기호 f를 적용한 결과를 나타낸다.

방정식을 지정할 때, 상수뿐만 아니라 변수도 사용할 수 있다.

Constants

우리는 다음과 같은 유형의 상수를 구별한다.

• 공개 상수(Public constants) : 공개적으로 알려진 원자적 메시지를 모델링하며, 예를 들어 에이전트 식별자 및 레이블이 이에 해당한다. Tamarin에서는 ident 표기법을 사용하여 공개 상수를 나타낸다. 이러한 상수는 pub 유형이며, 공개 변수와 통합(unification)될 수 있다. 항상 공격자가 알고 있는 값이다.

• 아리티(arity)가 0인 함수 (Functions of arity 0) : 항상 msg 유형이며, 공개 변수와 통합될 수 없다. 기본적으로 이 함수는 공개이며, 공격자가 알 수 있는 값이다. 그러나 함수가 private로 선언되면 공격자가 알 수 없는 값이 된다. 하지만 이 비밀 값을 모델링할 때는 보통 fresh값을 사용하는 것이 더 적절하다.

• 자연수(Natural Numbers) : 유일한 상수는 %1 또는 1:nat으로 표현되며, 숫자 1을 모델링한다.

Function Symbols

Tamarin은 내장된 함수 기호(built-in function symbols)와 사용자가 정의할 수 있는 추가 함수 기호(user-defined function symbols)를 지원한다. 모든 Tamarin 파일에서 기본적으로 사용할 수 있는 함수 기호는 쌍(pairing)과 투영(projection)이다.

• 이항(binary) 함수 pair: 두 개의 메시지를 하나의 쌍으로 결합
• fst 와 snd함수 : pair(x, y)에서 각각 첫 번째 요소 x와 y를 추출

이러한 투영 연산은 다음과 같은 방정식으로 정의된다.

fst(pair(x, y)) = x
snd(pair(x, y)) = y

또한 Tamarin은 다음과 같은 구문적 축약(Syntactic sugar)을 지원한다.

<x, y> = pair(x, y)
<x1, x2, ..., ,xn-1, xn> = <x1, <x2, ..., <xn-1, xn> ...>

특정한 메시지 이론(Message theories)를 활성화하면 추가적인 내장 함수 기호를 사용할 수 있다. hashing, asymmetric-encryption, signing, revealing-signing, symmetric-encryption, diffie-hellman, bilinear-pairing, xor, and multiset. 해당 메시지 이론의 정의는 Built-in message theories섹션에서 확인한다.

Tamarin은 또한 사용자 정의 함수 기호(User-defined function symbol)를 정의할 수 있다. 함수 기호를 정의하려면, 아리티(arity)값을 포함한 다음 줄을 파일에 추가해야 한다.

functions: f1/a1, ..., fn/an

여기서 f1/a1은 함수 f1이 a1개의 인수를 가진다는 의미

마지막으로, 비공개 함수 기호(Private function symbol)를 지원한다. 일반적인 함수 기호와 달리, 비공개 함수는 공격자가 사용할 수 없는 함수로 가정한다. 비공개 함수는 정직한(honest) 사용자들 사이에서 공유되는 비밀(secret)을 암시적으로 포함하는 함수를 모델링할 때 사용될 수 있다. 함수를 비공개로 만들려면, 함수 뒤에 [private] 속성을 추가하면 된다.

functions: f/3, g/2 [private], h/1

여기서 g는 비공개 함수이고, f, h는 공개 함수이다.

Equational theories

방정식 이론은 함수의 속성을 모델링하는 데 사용될 수 있다. 예를 들어, 대칭키 복호화가 대칭키 암호화의 역연산(inverse)이라는 성질을 표현할 수 있다. 방정식을 Tamarin의 컨텍스트(context)에 추가하려면 다음과 같은 구문을 사용한다.

equations: lhs1 = rhs1, ..., lhsn = rhsn

좌변(lhs)과 우변(rhs) 모두 변수를 포함할 수 있지만, 공개 상수(public constants)는 포함할 수 없다. 또한, 우변에 있는 모든 변수는 반드시 좌변에도 등장해야 한다. Tamarin에서 사용되는 기호적 증명 탐색(symbolic proof search)은 특정한 사용자 정의 방정식 클래스, 즉 유한 변형 속성(finite variant property)을 가지는 수렴 방정식 이론(convergent equational theories)을 지원한다. Tamarin은 주어진 방정식이 이 클래스에 속하는지 검사하지 않으므로, 해당 클래스를 벗어나는 방정식을 작성하면 무한 루프 또는 잘못된 결과가 발생할 수 있으며, 이에 대한 경고과 표시되지 않는다. 또한, Tamarin의 추론은 부분항 수렴 방정식만 고려할 때 특히 효율적이다. 즉, 우변이 기저 항(ground term, 변수를 포함하지 않는 항)이거나 좌변이 진부분항(proper subterm)인 경우, Tamarin의 효율성이 향상된다. 따라서, 필요한 속성을 모델링하는 데 충분한 경우 이러한 형태의 방정식이 선호된다.

그러나, Diffie-Hellman, bilinear-pairing, XOR, multiset과 같은 내장 메시지 이론에서 모델링된 방정식은 이러한 제한된 클래스에 속하지 않는다. 이는 예를 들어, 결합법칙(associativity)과 교환법칙(commutativity)을 포함하기 때문이다. 기타 모든 내장 메시지 이론은 functions: ... 및 equations: ...을 사용하여 동일하게 정의할 수 있으며, 다음 섹션에서 허용되는 방정식의 예시를 살펴보자.

Built-in message theories and other built-in features

f/n은 함수 기호 f가 n개의 인수를 가진 함수(arity n)임을 나타낸다.

hashing: 해시 함수를 모델링한다. 함수 기호는 h/1이고, 방정식은 없다.

asymmetric-encryption

• 정의: 공개키 암호화(public key encryption scheme) 모델
• 함수 기호: aenc/2, adec/2, and pk/1
• 방정식: adec(aenc(m, pk(sk)), sk) = m
• 구문적 축약: aenc{x, y}pkB = aenc(<x, y>, pkB)

signing

• 정의: 전자 서명(signature) 모델
• 함수 기호: sign/2, verify/3, pk/1, and true
• 방정식: verify(sign(m, sk), m, pk(sk)) = true

revealing-signing

• 정의: 메시지가 공개되는 서명 모델
• 함수 기호: revealSign/2, revealVerify/3, getMessage/1, pk/1, and true
• 방정식:

  revealVerify(revealSign(m, sk), m, pk(sk)) = true
  getMessage(revealSign(m, ks)) = m

symmetric-encryption

• 정의: 대칭키 암호화(symmetric encryption scheme) 모델
• 함수 기호: senc/2 and sdec/2
• 방정식: sdec(senc(m, k), k) = m

diffie-hellman

• 정의: 디피-헬만 그룹 모델
• 함수 기호: inv/1, 1/0, ^, and *
• 방정식:

  (x^y)^z = x^(y*z)
  x^1 = x
  x*y = y*x
  (x*y)*z = x*(y*z)
  x*1 = x
  x*inv(x) = 1
  

`bilinear-pairing`
- 정의: 쌍선형 그룹 모델
- 함수 기호: `pmult/2`, `em/2`
- 방정식:

pmult(x, pmult(y, p)) = pmult(x*y, p) pmult(1, p) = p em(p, q) = em(q, p) em(pmult(x, p), q) = pmult(x, em(q, p))

`xor`
- 정의: 배타적 논리합(XOR) 연산 모델
- 함수 기호: `⊕/2`(또는 `XOR/2`), `zero/0`
- 방정식: 

x ⊕ y = y ⊕ x (x ⊕ y) ⊕ z = x ⊕ (y ⊕ z) x ⊕ zero = x x ⊕ x = zero

`multiset`
- 정의: 다중집합 연산을 위한 모델
- 함수 기호: `++`
- 속성: 결합법칙 및 교환법칙 적용

`natural-numbers`
- 정의: 카운터(counter) 모델링
- 함수 기호: `%+`(덧셈 연산자), and `%1`
- 속성: 

    - 모든 자연수 값은 공개(public knowledge)이며, 공격자가 직접 구성할 필요 없음
    - 주로 작은 숫자(카운터 등)를 모델링하는 데 사용
    - 큰 랜덤 숫자를 모델링할 때는 `fresh` 변수를 사용하는 것이 권장됨
- WPA-2 프로토콜 예시
``` prolog
<~x, %n>

• ~x : 랜덤한 시작값
• %n : 공격자가 추측할 수 있는 카운터 값

reliable-channel

• 정의: 프로세스 계산에서 신뢰할 수 있는 채널을 지원

• 채널 종류:

  • r : 신뢰할 수 있는 채널 (메시지는 반드시 도착)
  • c : 공개 및 신뢰할 수 없는 채널

• 다중 채널 모델링 예시

  out('r', <'channelA', 'Hello')
  | out('r', <'channelB', 'Bonjour')
  | in('r', <'channelA', x); event PrepareTea()
  | in('r', <'channelB', x); event PrepareCoffee()

Reserved function symbol names

다음 함수 이름들은 사용자 정의 함수의 이름으로 사용될 수 없다. mun, one, exp, mult, inv, pmult, and em. 어떤 이론에서 위 함수 기호 중 하나라도 사용자 정의 함수로 표현하면, parser는 해당 파일을 거부하며, 어떤 예약된 이름이 재정의되었는지를 명확히 표시할 것이다.

Initial Example

Graphical User Interface

우리가 작성한 lemma들이 옳은지 어떻게 증명할까?

$ tamarin-prover interactive FirstExample.spthy

기본적으로 오류 없이 컴파일이 잘 되면, http://localhost:3001 주소로 Tamarin GUI가 열린다. 브라우저에서 확인해보자.

Installation의 경우, Tamarin github나 manual을 참고하자. macOS, Linux의 경우 brew 패키지 인스톨러를 이용한 설치가 가장 간편하다.

실행 시 위와 같은 화면을 볼 수 있다. 분석을 원하는 파일을 클릭하여 확인하면 된다. 'FirstExample'파일을 클릭하여 분석해보자.

화면 왼쪽은, theory가 표시되며, 여기에는 다음과 같은 요소들이 포함된다.

• 메시지 이론(Message theory): 공격자(adverary)를 설명하는 부분
• 멀티셋 재작성 규칙(Multiset rewriting rules): 프로토콜을 설명하는 규칙과 제약조건
• 원시 소스(Raw source) 및 정제 소스(Refined source): 분석 과정에서 사용되는 소스들
• 증명하고자 하는 정리(lemmas): 검증해야 할 명제들

화면 오른쪽에는, 몇 가지 메뉴와 단축키들이 적혀 있다.

화면 왼쪽의 Message theory를 클릭하면 화면 오른쪽에 메시지 이론들이 나열된다.

Signature로 시작하는 부분에서, 모든 functions와 equations들을 확인할 수 있다. 이것들은 사용자 정의(user-defined)이거나 built-ins를 사용하여 임포트된 것이다.

Tamarin은 자동으로 괄호쌍을 위해 pair라는 함수를 추가한다. 또한, fst와 snd를 함께 추가한다. 각각 pair의 first 요소와 second 요소를 반환하는 방정식이다. fst(<x.1, x.2>) = x.1에서 볼 수 있듯이 <, >는 pair의 약칭(shorthand)이다.

Construction Rules의 규칙들은 공격자가 적용할 수 있는 기능들(functions)을 나타낸다.

rule (modulo AC) ch:
    [ !KU(x) ] --[ !KU(h(x)) ]-> [ !KU(h(x)) ]

직관적으로 이 규칙은 다음을 의미한다.

• 전제(premise)에서 !KU(x)가 존재한다는 것은 공격자가 x를 알고 있음을 의미한다.
• 결론(conclusion)에서 !KU(h(x))가 존재한다는 것은 공격자가 x를 해싱하여 h(x)를 계산할 수 있다는 것을 의미한다.

즉, 공격자는 어떤 값을 알고 있다면, 그 값의 해시도 계산할 수 있다. 라벨(label)에 포함된 !KU(h(x))는 이 과정이 증명 과정에서 논리적으로 추론될 수 있도록 기록됨을 의미한다.

마지막으로 Deconstruction rules는 함수를 적용함으로써 큰 terms로 부터 공격자가 추출할 수 잇는 term들을 의미한다.

rule (modulo AC) dfst:
    [ !KD(<x.1, x.2>) ] --> [ !KD(x.1) ]

이 규칙은 공격자가 <x.1, x.2> 쌍을 알고있다면, 첫 번째 값인 x.1을 추출할 수 있다는 것을 의미한다. 이것은 pair에 대한 fst의 적용과 fst(<x.1, x.2>) equation의 결과이다. !KD() 와 !KU()는 모두 공격자의 지식을 의미하는데 둘을 구분하는 이유는, Tamarin의 논리적 추론을 보다 효율적으로 만들기 위해서이다.

위 그림은 Multiset rewriting rules를 클릭하면 볼 수 있는 화면이다. 화면의 오른쪽은 프로토콜의 재작성 규칙들과 2개의 추가적인 규칙들:isend, irecv을 볼 수 있다. 이 추가적인 규칙들은 프로토콜의 입/출력과 공격자의 추론 간의 인터페이스를 제공한다. isend는 !KU(x)를 In(x) 프로토콜의 입력값으로 전달한다. (공격자가 자신이 알고 있는 정보를 프로토콜에 보낼 수 있음을 나타냄) 반면, irecv는 Out(x) 프로토콜의 출력값을 받아 공격자의 지식(!KD(x))으로 전달한다. (프로토콜이 보낸 데이터를 공격자가 수신할 수 있음을 나타냄)

Serv_1규칙은 2개의 variants(변이) (modulo AC)를 가진다는 것에 유의해라. 정확한 의미는 cryptographic messages 섹션에서 설명하겠다.

Refined sources를 클릭하면 위와 같은 화면을 볼 수 있다. Tamarin은 내부적인 추론 효율성을 높이기 위해서 사전 계산(Precomputation) 과정에서 경우 구분(Case distinctions)을 수행한다. 경우 구분은 특정한 사실(fact)의 모든 가능한 출처(sources)를 미리 분석하는 과정이다. 즉, 어떤 규칙(또는 규칙의 조합)이 해당 사실을 생성할 수 있는지 미리 계산한다. 이렇게 사전 계산된 정보는 Tamarin의 역방향 탐색(backward search) 과정에서 활용된다. 이를 통해 같은 사실을 반복적으로 계산하는 비효율성을 방지할 수 있다.

예를 들어, Tamarin은 !Ltk(t.1, t.2) 사실의 가능한 출처가 단 하나뿐임을 알려준다. 즉, 이 사실은 Register_pk 규칙에서만 생성될 수 있다.

• green box : Register_pk의 인스턴스를 나타냄
• trapezoid(사다리꼴) : !Ltk(t.1, t.2) 사실의 sink(최종 도착지)를 의미함

경우 구분(case distinction) 이 예시에서는 단 하나의 규칙(Register_pk)만 해당 사실을 생성할 수 있지만, 경우에 따라 여러 개의 규칙 인스턴스가 존재할 수도 있음 또한, 하나의 경우 구분 내에 여러 개의 가능한 시나리오(다양한 규칙 조합)가 포함될 수 있음

기술 정보(the technical information) Tamarin이 경우 구분을 어떻게 계산했는지, 해결해야할 추가적인 제약(방정식, 치환 등)이 있는지에 대한 세부 정보를 제공한다.

3개의 출처(sources)를 가지는 !KU(~t.1) 사실이 있다. 첫 번째는 Reveal_ltk 규칙이다. 이 규칙은 !Ltk 사실을 생성하기 위한 Register_pk 규칙의 인스턴스를 요구한다.

나머지 2개의 source들은 아래 그림으로 대체한다.

이제 interactive 모드에서 어떻게 lemma들을 검증하는지 볼 것이다. 검증하기 위해서, sorry(검증이 시작되지 않았다는 것을 나타냄)를 클릭한다.

Tamarin은 제약 해결(constraint solving)을 사용하여 lemma를 검증한다. 구체적으로, Tamarin은 프로토콜과 해당 보안 속성(property)에 대해 알고 있는 정보를 계속해서 정제(refine)하면서 분석을 진행한다. 이 과정은 제약 시스템(constraint system)을 기반으로 수행된다.

증명 과정의 결과는 두 가지로 나뉜다:

• 모든 가능한 경우에서 해당 속성이 성립함을 증명 → 정리(lemma)가 참임이 입증됨.
• 반례(counterexample)를 찾아 속성이 성립하지 않음을 증명 → 정리(lemma)가 거짓임을 입증하고, 취약점이 존재할 가능성을 시사.

즉, Tamarin은 가능한 모든 시나리오를 분석하여 lemma가 참인지 거짓인지 판별하는 방식으로 보안 프로토콜을 검증한다.

우리는 이제 위에서부터 가능한 검증 절차와 제약 시스템의 현재 상태를 가진다. 아직 검증을 하지 않았기 때문에 제약 시스템은 빈 상태이다. 검증은 항상 단순화 과정( 1.simplify)이나 귀납 과정(2.induction)에서 부터 시작된다.

• simplify : lemma를 초기 제약 시스템(initial constraint system)으로 변환하며, 해당 제약 시스템을 해결해야 한다.
• induction : 실행(trace)의 길이에 대한 귀납(induction)을 사용하여 lemma를 증명하는데 필요한 제약을 생성한다.

simplify를 클릭하면 다음과 같은 결과를 얻을 수 있다.

Tamarin이 lemma를 제약 시스템으로 변환했다. 이제 lemma의 반례를 찾으려한다. 즉, 다음 조건을 만족하는 프로토콜 실행(protocol execution)을 찾는다.

• SessKeyC(S, k) 액션이 존재
• K(k) 액션이 존재
• 하지만, LtkReveal(S) 이 사용되지 않음

이것은 그래프로 시각화되어 있다. SessKeyC(S, k) 액션을 얻는 것은 오직 Client_2 규칙의 인스턴스를 사용하는 것이다. K(k) 규칙은 라운드 박스(공격자의 논리적 추론은 항상 라운드 박스를 사용하여 나타낸다)로 표현되었다.

그래프 아래에는 다음과 같은 공식을 볼 수 있다.

∀ #r. (LtkReveal(S) @ #r) ⇒ ⊥

이제 LtkReveal(S)의 발생은 모순으로 이어질것이라고 말한다. 증명을 마치기 위해서, 우리는 다음 해결할 제약들을 선택함으로써 수동적으로 계속할 수도 있고 autoprove 명령을 호출할 수 도 있다. 우리는 2개의 제약을 해결해야 한다. (Client_1(S, k), KU(k)) 두 제약 모두 현재 종료되지 않은 제약 시스템의 규칙들을 위한 전제조건(premises)들이다.

GUI에서 제공되는 증명 방법은 autoprove명령어에서 사용되는 것과 동일한 휴리스틱(heuristic)에 따라 정렬된다.

• 항상 첫 번째 증명 방법을 선택하면, autoprove명령어가 생성하는 증명과 동일한 증명이 수행됨
• 하지만, 일반적으로 보안 프로토콜 검증 문제는 결정 불가능(undecidable)하기 때문에, 일부 프로토콜 및 속성(Property)에 대해 알고리즘이 종료되지 않을 수 도 있다.

해당 예제에서는 첫 번째 제약을 여러 번 클릭하거나, autoprover를 사용하면 다음과 같은 최종 상태(final state)에 도달하게 된다.

이 최종 상태에서 생성된 그래프(Constructed graph)가 모순(Contradiction)으로 이어지는데, 그 이유는 그래프에 LtkReveal(S)이 포함되어 있기 때문이다.

lemma는 이제 초록색으로 색칠되고 성공적으로 증명되었다는 것을 의미한다. 만약 반례를 찾았다면, 붉은색으로 칠해질 것이다.

Tamarin의 그래프에서는 다양한 종류의 화살표가 사용되며, 각각 다른 의미를 갖는다.

• 일반적인 검은색 또는 회색 실선(solid) 화살표는 프로토콜의 사실(facts)의 기원(origin)을 나타낸다.
• 붉은색 또는 주황색 실선은 공격자가 받은 메시지에서 값을 추출하는 과정을 나타낸다.

점선 화살표(Dashed arrows)의 경우 두 개의 액션 사이에 순서(ordering) 제약이 있음을 나타낸다.

• 검은색 점선 : 공식(formulas)에서 유도된 순서 제약 (lemma나 특정 restriction에서 유래)
• 진한 파란색 : 새로운(fresh) 값에서 유도된 순서 제약 (새로운 값은 반드시 그 값을 생성한 후에만 사용될 수 있음)
• 빨간색 점선 : 공격자가 값을 조합하는 과정에서 발생하는 단계
• 진한 주황색 점선 : Tamarin의 정규형 조건(normal form conditions)에서 유도된 순서 제약
• 보라색 점선 : 단사적 사실(Injective Fact)에서 기인한 순서 제약 (ex. 특정한 값이 한 번 만 사용될 수 있음)

초록색 점선 화살표는 Tamarin의 증명 과정에서 불완전한(adversary deduction) 추론 단계를 나타낸다. 즉, 공격자가 특정 값을 유추하는 과정에서 아직 완전히 증명되지 않은 단계를 시각적으로 표현할 때 사용된다.

그래프에서 약어(abbreviations) 사용 옵션을 사용하면 길거나 반복되는 항(term)들을 약어로 변환하여 표시할 수 있다.

Reference

Tamarin Homepage

Introduction

Tamarin prover(이하 Tamarin)는 보안 프로토콜의 심볼릭 모델링과 분석을 위한 툴이다. 보안 프로토콜 모델을 입력으로 받아, 프로토콜을 실행하는 에이전트들이 다양한 역할(예: 프로토콜 시작자(Initiator), 응답자(Responder), 신뢰할 수 있는 키 서버)에서 취하는 행동을 명시하고, 적대자의 명세와 프로토콜의 원하는 속성을 명시합니다.

Tamarin은 프로토콜의 여러 역할 인스턴스가 병렬로 무작위로 얽혀 실행되더라도, 그리고 공격자의 행동이 함께 포함되더라도, 프로토콜이 지정된 속성을 충족한다는 것을 자동으로 증명할 수 있도록 사용될 수 있다.

Initial Example

https://github.com/tamarin-prover/manual 의 FirstExample.spthy를 이용한다.

Alice-and-Bob notation:

C -> S: aenc(k, pkS) C <- S: h(k)

client C가 새로운 대칭키 k를 생성하고, server S의 공개키 pkS로 k를 암호화하여 S에게 전달한다. (aenc는 asymmetric encryption*의 약어이다) 서버는 클라이언트에게 k의 해시를 전송함으로써 키의 수신을 확인한다. 적대자 adversary는 *Dolev-Yao 모델이기에, 네트워크를 통제하고 네트워크 상의 메시지들을 삭제하고, 삽입하고(Inject), 수정하고 가로챌 수 있다.

Tamarin 파일은 theory 키워드로 시작한다.

theory FirstExample
begin

body는 begin 과 end 키워드 사이에 작성한다.

Cryptographic primitives

builtins는 Tamarin에서 제공하는 함수 API라고 생각하면 된다. 해당 예제에서는 hashing, asymmetric-encryption을 사용한다. 해당 built-ins는 다음과 같은 함수를 제공한다.

• a unary function h, denoting a cryptographic hash function

• a binary function aenc denoting the asymmetric encryption algorithm

• a binary function adec denoting the asymmetric decryption algorithm

• a unary function pk denoting the public key corresponding to a private key

(cf. adec(aenc(m, pk(sk)), sk)는 m을 반환한다.)

Modeling a Public Key Infrastructure

Tamarin에서, 프로토콜과 그 환경을 multiset rewriting rules를 사용하여 모델링 한다. Rule들은 시스템의 상태에 작용하며, 이 상태는 Fact들의 멀티셋(즉, 중복을 허용하는 집합, bag)으로 표현된다. 여기서 Fact들은 시스템의 상태 정보를 저장하는 논리적 술어(predicates)로써 보여질 수 있다. 즉, 각 사실은 현재 시스템이 어떤 상태에 있는지를 나타내는 역할을 한다. 예를 들어서, Out(h(k))는 프로토콜이 메시지 h(k)를 퍼블릭 채널에서 보냈다는 것을 의미한다. In(x)는 프로토콜이 퍼블릭 채널에서 메시지 x를 받았다는 것을 의미한다.

우리는 논쟁에 의해서 주어진 상태에 대한 정보를 저장하기 위해서 fact를 사용한다. 규칙들(rules)은 -->심볼로 분리되는 premise와 conclustion을 가진다. rule을 실행하는 것은 premise의 모든 fact들이 현재 상태에 존재하는 것을 필요로하고, 실행의 결과로써, premise들이 지워지는 반면에 conclusion에 있는 fact들은 상태에 더해질 것이다.

rule Register_pk:
    [ Fr(~ltk) }
    -->
    [ ~Ltk($A, ~ltk), !Pk($A, pk(~ltk)) ]

이 예제에서 premise는 오직 Fr fact의 인스턴스이다. Fr은 freshly generated name을 의미하는 built-in fact이다. 이러한 매커니즘은 nonces나 keys와 같은 랜덤한 숫자를 모델링하는데 사용된다.

• ~x denotes x:fresh

• $x denotes x:pub

• %x denotes x:national number

• #i denotes i:temporal

• m denotes m:msg

문자열 상수 c는 퍼블릭 네임 pub를 의미한다. 이것은 pub에 속하는 고정된 글로벌 상수이다. (변하지 않는 공용 식별자 같은 역할을 한다.)

정렬(Sort) msg는 최상위 정렬이다. msg 아래에 세 개의 서로 비교할 수 없는(incomparable) 하위 정렬이 존재한다.

• fresh

• pub

• nat 비교할 수 없다라는 것은 fresh, pub, nat이 서로 포함 관계가 없고, 직접적으로 크기를 비교할 수 없는 독립적인 정렬이라는 뜻이다.

시간 변수(Timepoint variables) 시간 변수는 temporal이라는 정렬을 가지며, 서로 연결되지 않은(unconnected) 독립적인 변수들이다.

따라서 위 예제는 다음과 같이 읽힐 수 있다. 먼저 ~ltk (sort of fresh), 새로운 private key를 생성했고, 키 쌍을 생성하기 위한 agent를 위해서 정해져있지 않은(non-deterministically) 공개 이름 A를 선택했다. 그 후, agent A와 private key ~ltk간의 관계를 의미하는 !Ltk($A, ~ltk)라는 fact를 생성했다. (exclamation mark !는 fact가 영구적이다라는 것을 의미한다.) 그리고, A와 그의 공개 키 pk(~ltk)를 연관짓는 !Pk($A, pk(~ltk)) fact를 생성한다.

해당 예제에서, 다음 규칙을 사용하여 적대자가 어떠한 공개키라도 얻게 할 수 있다. 필수적으로, 이 규칙은 공개 키 데이터베이스에서 엔트리를 읽고 built-in fact Out을 사용하여 네트워크로 공개 키를 전송한다.

rule Get_pk:
    [ !Pk(A, pubkey) ]
    -->
    [ Out(pubkey) ]

우리는 다음과 같은 규칙을 사용하여 long-term private key(장기 개인 키)의 동적 노출(dynamic compromise)를 설계할 수 있다. 직관적으로, 해당 규칙은 private-key 데이터베이스에서 항목을 엔트리를 읽고 적대자에게 그것을 전송하는 과정을 나타낸다. 이 규칙은 LtkReveal이라는 행동을 가지며, 이는 agent A의 long-term key가 노출되었다는 것을 의미한다. Action fact들은 fact와 유사하지만, 상태(State)에 남지 않고 오직 추적(Trace)에서만 나타난다. 보안 속성(The security properties)들은 이 추적들을 기반으로 정의되고, LtkReveal은 어떤 agent들이 노출되었는지를 판단하는데에 사용된다.

rule Reveal_ltk:
    [ !Ltk(A, ltk) ]
    --[ LtkReveal(A) ]->
    [ Out(ltk) ]

Modeling the protocol

Alice-and-Bob 모델을 돌이켜보자.

C -> S: aenc(k, pkS)
C <- S: h(k)

우리는 이것을 다음과 같은 3개의 규칙들로 모델링할 수 있다.

// Start a new thread executing the client role, choosing the server
// non-deterministically

rule Client_1:
    [ Fr(~k)                    // choose fresh key
    , !Pk($S, pkS)                // lookup public-key of server
    ]                
    -->
    [ Client_1($S, ~k)            // Store server and key for next step of thread
    , Out(aenc(~k, pkS))         // Send the encrypted session key to the server
    ]        

rule Client_2:
    [ Client_1(S, k)            // Retrieve server and session key from previous step
    , In(h(k))                    // Receive hased session key from network
    ]
    --[ SessKeyC(S, k) ]->        // State that the session key 'k'
    []                            // was setup with server 'S'


// A server thread answering in one-step to a session-key 
// setup request from some client.

rule Serv_1:
    [ !Ltk($S, ~ltkS)                        // lookup the private-key
    , In(request)                            // receive a request
    ]
    --[ AnswerRequest($S, adec(request, ~ltkS)) ]->      // Explanation below
    [ Out(h(adec(request, ~ltkS) ]            // Return the hash of 
                                            // the decrypted request.

해당 코드에 대하여 몇 가지 설명이 필요한데,

• 첫 번째 규칙은 메시지를 전송하는 것이고, 두번째 규칙은 응답을 받는 것을 의미한다.
• 세 번째 규칙은 하나의 규칙으로 작성한 메시지를 수신하고 응답하는 서버를 의미한다.
• Tamarin은 C-style의 주석을 사용한다.
• 서버가 받은 세션-키 설정 요청을 행동(action)으로 기록(log)하여, 추후에 클라이언트의 인증 속성을 형식적으로 정의할 수 있도록 한다.

Modeling security properties

보안 속성들은 프로토콜의 실행의 action fact들의 추적들 위에서 정해진다. 우리는 평가할 2가지 보안 속성들을 가지고 있다. Tamarin에서 평가될 보안 속성들은 lemmas로 표현된다.

첫 번째 평가할 속성은 클라이언트 시점으로부터 세션키의 기밀성(Secrecy)이다. Client_session_key_secrecy라는 lemma는 클라이언트가 서버 S와 세션 키 k를 설정한 경우, 적대자가 k를 알게 되는 것은 오직 적대자가 서버의 long-term key를 노출시켰을 때만 가능하다는 것이다.

두 번째 lemma인 Client_auth는 클라이언트 인증을 의미한다. 이것은, 클라이언트가 서버 S와 설정한 모든 세션 키 k에 대하여, 반드시 요청에 대해 응답한 서버가 존재하거나 적대자가 이전에 S에 대한 long-term key 노출을 수행했다는 것을 의미한다. (정상적인 상황에서는 클라이언트가 세션 키를 설정했을 때 반드시 대응하는 서버가 있어야 하며, 만약 그렇지 않은 경우 공격자가 서버의 장기 키를 노출시킨 경우에만 예외가 발생할 수 있음을 의미한다.)

lemma Client_session_key_secrecy:
" /* It cannot be that a */
  not(
    Ex S k #i #j.
      /* client has set up a session key 'k' with a server'S' */
      SessKeyC(S, k) @ #i
      /* and the adversary knows 'k' */
    & K(k) @ #j
        /* without having performed a long-term key reveal on 'S'. */
    & not(Ex #r. LtkReveal(S) @ r)
  )
"


lemma Client_auth:
" /* For all session keys 'k' setup by clients with a server 'S' */
  ( All S k #i. SessKeyC(S, k) @ #i
    ==>
        /* there is a server that answered the request */
    ( (Ex #a. AnswerRequest(S, k) @ a)
        /* or the adversary performed a long-term key reveal on 'S'
            before the key was setup. */
    | (Ex #r. LtkReveal(S) @ r & r < i)
    )
  )
"

우리는 또한 인증 속성을 더 강화하여 injective 인증 버전을 만들 수 도 있다. 우리의 공식화(formulation)는 일반적인 injective 인증보다 더 강력한 형태이다. 그 이유는 단순한 개수(counting)에 기반한 것이 아니라, 고유성(uniqueness)에 기반하기 때문이다. 대부분의 프로토콜이 injective 인증을 보장하는 경우, 적절한 새 데이터(fresh data)에 대한 합의가 이루어진다면, 고유성 주장도 증명할 수 있다. 이 속성은 Client_auth_injective lemma에서 볼 수 있다.

lemma Client_auth_injective:
    "    /* For all session keys 'k' setup by clients with a server 'S' */
        ( All S k #i. SessKeyC(S, k) @ #i
            ==>
                /* there is a server that answered the request */
            (    (Ex #a. AnswerRequest(S, k) @ a
                & ( All #j. SessKeyC(S, k) @ #j ==> #i = #j)
            )
                /* or the adversary performed a long-term key reveal on 'S'
                before the key was setup. */
            |    (Ex #r. LtkReveal(S) @ r & r < i)
            )
        )
    "

우리의 lemma가 단순히 모델이 실행 불가능하기 때문에 공허하게(vacuously) 성립하는 것이 아님을 보장하기 위해서, 모델이 실제로 실행될 수 있고 완료될 수 있음을 보이는 실행 가능성(Excutability) lemma를 포함한다. 이 lemma는 일반적인 lemma와 동일한 형식으로 작성되지만, exists-trace라는 키워드로 표현된다. 이 키워드는 이 lemma가 참이 되려면, 이 공식을 만족하는 실행(trace)이 하나라도 존재해야 한다.는 의미이다. 이는 이전의 lemma들과 대조되는데, 이전 lemma들은 모든 trace에서 성립해야 한다는 조건을 요구했다. 프로토콜을 모델링할 때, 이러한 존재성 증명(Existence proof)은 모델의 타당성을 확인하는 중요한 무결성 점검(sanity check)이 된다.

lemma Client_session_key_honest_setup:
    " Ex S k #i.
        SessKeyC(S, k) @ #i
      & not(Ex #r. LtkReveal(S) @ r)
    "

범용 컴퓨터 시스템의 목적

• **CPU의 활용률(Utilization)을 극대화

• 사용자에게 빠른 응답을 제공 보다 많은 Program을 Memory에 올려서 실행 (Multi-Programming) 여러 Program을 동시에 실행시키기 위한 Scheduling 기법 등장

Memory 관리의 필요성 등장

• 여러 Program이 동시에 Memory에 적재되어 실행되면서, Memory를 공유할 필요가 생김

• Computer의 Memory는 한정된 자원

• 실행하는 Program이 많아지면 Memory 요구량이 증가*

주소 공간 (Address Space)

정의 (Address Sapce)

• Process에서 참조할 수 있는 주소들의 범위(집합)

• Processdhk 1:1 관계

• 사용자 Thread는 주소 공간을 공유함

주소 공간의 크기

• **CPU의 주소 버스(Address Bus)의 크기에 의존

• 주소 버스가 32bit인 System에서 주소 공간의 크기 $2^{32}$개의 서로 다른 주소에 대한 식별자를 만들 수 있으므로, 0부터 ($2^{32} - 1$)까지의 주소 범위를 Addressing 할 수 있음

• 32bit 주소 버스를 가진 System이 주소 1개당 1Byte의 Memory를 접근할 수 있다면, 이 System이 Address할 수 있는 주소공간의 크기는? $2^{32} * 1Byte = 4GB$

물리 주소와 가상 주고 (PA and VA)

물리 주소 (Physical Address)

• 컴퓨터의 메인 메모리를 접근할 때 사용되는 주소

• 기억 장치의 주소 레지스터에 적재되는 주소

가상 주소 (Logical Address or Virtual Address)

• Process의 관점에서 사용하는 주소

• CPU 관점의 주소는 물리 주소도, 가상 주소도 될 수 있음 어느 Memory Model을 사용하느냐에 따라 잘라짐

• Logical이기 때문에 주소 공간을 의미 있는 단위로 나누어 사용하지 않음

초창기 컴퓨터의 주소 관리

물리 주소를 Compile Time에 생성

• Compiler는 Process가 물리 Memory에서 실행되는 주소를 Compile Time에 알아서 절대 코드를 생성한다.

• 시작 주소의 위치가 바뀔 경우에는 다시 Compile을 해야 한다.

  다양한 Program이 실행됨에 따라 Compile Time에 물리 주소를 정하기가 어려워짐

• 1개의 Program이 실행될 경우 문제가 없음

• Multiprogramming의 경우, Compile Time 시에 결정된 주소는 다른 Program과 동시에 Memory에 Load하기 어려움 => 가상 주소를 생성하기 시작함

Compile 및 Link Time에서의 주소 결정

Compile Time

• Compiler가 Symbol Table을 만들고 주소는 Symbol Table Relative한 주소로 이루어짐

• **Compile된 Object파일은 주소 0부터 시작함 (Relocatable)

Link Time

• Object 파일들과 System에서 제공하는 Library들을 묶어서 Symbol Table에 의존적이지 않은 주소를 만들어 냄

• Link의 결과로 하나의 Executable파일이 만들어진 주소는 0부터 시작함 (아직도 논리주소로...)

• Executable은 하나의 주소 공간으로 0부터 시작함

Load Time

• Program의 실행을 위해 Loader는 Executable을 Memory로 Load한다.

• 주소 공간 전체가 Memory에 올라간다면, Load 시에 물리 주소에 대한 Binding이 일어난다.

• Program은 Relocatable 주소로 되어 있기 때문에* Base Register를 통해서 물리 주소로 바꾸어 실행하게 된다.

• 만일 Program의 시작 주소를 바꾸려면, 다시 Load를 해야한다.

Execution Time

• Process가 실행 될 때 물리 주소가 바뀌는 경우, 물리 주소에 대한 Binding은 Process가 실행될 때 일어난다.

• ** 이러한 형태의 주소 결정 방법을 사용하기 위해서 MMU와 같은 특별한 H/W가 필요하게 된다.**

• 대부분 General Purpose 운영체제에서는 이 방식을 사용한다

CPU에서 사용하는 주소에 따른 변환 방법

CPU에서 Physical Relative Address를 사용하는 경우

• Program 내 Instruction들의 주소를 시작 주소(Base Address)로 부터의 상대적인 Offset으로 표현하는 방법

• 시작 주소가 결정되면 시작 주소(Base Address) + 상대 주소의 합으로 절대 주소를 생성할 수 있다.

CPU에서 Virtual Address를 사용하는 경우

Translation의 속도가 중요한 요소가 된다.

Memory Management Unit (MMU)

Virtual Address와 Physical Address 간의 변환을 수행하는 Hardware 장치

가상 메모리

정의

• Memory로서 실제 존재하지는 않지만, 사용자에게 Memory로서의 역할을 하는 Memory(Virtual)

Basic Idea

• Process가 수행 되기 위해서 Program의 모든 부분이 실제 메모리 (Physical Memory)에 있을 필요는 없다 현재 실행되고 있는 Code 부분만이 실제 Memory에 있으면 Process는 실행이 가능

가상 메모리 구현

가상 메모리 - Address Mapping Table

Paging

Paging

주소 공간을 동일한 크기인 Page로 나누어 관리

• 보통 1 Page의 크기는 4KB로 나누어 사용

• 프레임(Frame)

• 물리 Memory를 고정된 크기*로 나누었을 때, 하나의 Block

• 페이지(Page)

• 가상 Memory를 고정된 크기*로 나누었을 때, 하나의 Block

각각의 프레임 크기와 페이지 크기는 같다. (프레임과 페이지는 물리 메모리, 가상 메모리에서 부르는 용어의 차이)

Page가 하나의 Frame을 할당 받으면, 물리 Memory에 위치하게 된다

• Frame을 할당 받지 못한 Page들은 외부 저장장치(Backing Storage)에 저장된다 Backing Storage도 Page, Frame과 같은 크기로 나누어져 있다.

Paging - Page번호와 Offset

CPU가 관리하는 모든 주소는 두 부분으로 나뉜다

• Page 번호 각 Process가 가진 Page 각각에 부여된 번호 ex) 1번 Process는 0부터 63까지의 Page를 가지고 있음

• Page 주소 각 Page의 내부 주소를 가리킴 ex) 1번 Process 12번 Page의 34번째 Data

Page Table

페이지 테이블(Page Table)

• 각 Process의 Page 정보를 저장함

• Process마다 하나의 Page Table을 가짐*

• index: Page 번호

• 내용: 해당 Page에 할당된 물리 Memory(Frame)의 시작 주소 이 시작 주소와 Page 주소를 결합하여 원하는 Data가 있는 물리 Memory 주소를 알 수 있음

Page Table의 구현

• Page Table은 물리 Memory에 위치함 (PTBR로 접근)

• Page Table 기준 레지스터(PTBR: Page Table Base Register)가 물리 Memory 내의 Page Table을 가리킴

• Page Table 길이 레지스터(PTLR: Page Table Length Register)가 Page Table의 Size를 나타냄

page table의 인덱스는 page 번호 page table의 내용은 물리 Memory(Frame)의 시작 주소

Page Table - Page Table을 이용한 주소 변환

Page Table Entry (PTE)

PTE란?

• Page Table의 Record

  PTE의 각 필드 내용

• Page Base Address 해당 Page에 할당된 Frame의 시작 주소

• Flag Bits

  • Accessed Bit page에 대한 접근이 있었는지
  • Dirty Bit Page 내용의 변경이 있었는지
  • Present Bit 현재 Page에 할당된 Frame이 있는지
  • Read/Write Bit 읽기/쓰기에 대한 권한 표시

Translation Look-aside Buffers (TLB)

Paging방법에서는 Data로의 접근이 항상 두 번의 Memory 접근을 거쳐야 함

• Page Table에 한 번, 물리 Memory 내의 Data에 한 번
• Memory 접근 속도를 크게 떨어뜨림

해결 방법 - TLB in MMU

• Page Table을 이용해 변환된 주소를 TLB에 저장해 둠

• 다음 접근 시에는 TLB에 저장된 값을 이용하여 빠르게 변환된 주소를 얻을 수 있음 TLB는 Register(CPU내에 존재)이기 때문에, 빠른 수행이 가능함

• TLB Hit Ratio TLB 내에서 원하는 주소를 찾을 수 있는 확률 (높을수록 Memory 접근 속도를 향상시킬 수 있음) 위의 사진과 달리 Page Table에 접근하기 전, TLB에 먼저 접근하는 것을 볼 수 있다

다양한 Paging Table

Multilevel Page Table

다단계(Multi-level) Page Table의 필요성

• System의 발전에 따라 가상 주소 공간도 매우 큰 용량을 요구하게 됨
• 그로 인해 Page Table의 크기가 커지고, 그 차지하는 공간에 의해 Paging이 잘 이루어질 수 없게 되고 있다

32bit 가상 주소 공간을 가지는 System에서 Page의 크기가 4KB이면, 페이지에 접근하기 위한 Bit의 수는 20bit(= 1MB)이고, (12bit는 page offset) PTE는 보통 4B의 크기를 가짐. => page table은 4MB의 크기를 가지게 됨.

프로세스마다 페이지를 소유하고 있기 때문에 (+ 페이지는 물리 메모리에 존재하기 때문에) 100개의 프로세스가 떠있다면, 물리 메모리에 페이지 테이블을 위해서 400MB가 할당되어야 함

2 Level Page Table 구현

구현 방법

• Outer Page Table을 하나 더 두어, Page Table들을 가리키도록 한다. ex) 앞 선 예시에서, 20Bit를 차지하는 Page번호를 다시 아래와 같이 나눈다
• 10Bit Page 번호
• 10Bit Page 주소

도식

2 Level Page Table의 Table walk

Page Table Level과 Memory 성능

하나의 주소공간을 Mapping하는 Page Table이 차지하는 Memory

• 2 Level인 경우와 1 Level인 경우 Page Table 전체가 차지하는 Memory

Page Table의 Level이 많은 경우 장점

• Level이 3인 경우 생각해보기
• 어떨 때 Page Table이 차지하는 Memory가 줄어들까?

단점

• Table Walk에 걸리는 시간이 증가함

Inverted Page Table - 동기

Multilevel Page Table에서와 같은 Page Table의 용량 증가 문제를 해결하기 위한 다른 방법

• 64bit 주소 공간의 System에서 Multilevel Paging을 위한 정보의 크기는 32bit에 비해 현격하게 증가됨

해결 방법

• 아무리 가상 Memory의 공간이 크더라도, 물리 Memory의 크기에는 한계가 있음
• 모든 물리 Memory는 가상 Memory의 Page에 Mapping될 확률이 높음

Inverted Page Table - Think Different

기존 방식은 Page#을 이용하여 Frame#을 검색

Inverted 방식은 CPU에서 참조하는 Address와 PID조합으로 Page ID를 만들어 Page Table 내에서 Page ID를 검색함

• Page ID를 발견하면, 해당 Frame#을 Logical Address 공간으로 Mapping

Inverted Page Table - 구현

System 전체에 하나의 Page Table만 둔다

• Page Table Index : Frame의 번호

• Page Table 내용 : Process 번호(PID)와 Page 번호, Page 주소를 함께 넣음

Page Table은 보다 적은 용량을 차지하지만, Table을 검색하는데 시간이 오래 걸린다

-> Multilevel로도 페이지 테이블의 용량을 줄일 수 있기에... 그렇게 많이 사용하는 방식은 아닌듯

도식

Demand Paging

Demand Paging이란?

• Process의 실행을 위한 모든 Page를 Memory에 올리지 않고, 필요한 Page의 요청이 발생할 때 메모리에 올리는 Paging 기법

Paging service를 통해서 한 Process에 필요한 Page를 Memory와 Secodary Storage 간에 이동시킴

Valid and Invalid PAge

Valid하다는 것은 page가 Secondary Storage가 아닌, 메모리에 올라와 있다는 것을 의미함

장점

• **실행을 위한 물리 Memory 구성의 시간이 줄어든다

• Process의 전체 이미지를 Memory에 올리지 않기 때문에, 실제 필요한 전체 물리 Memory의 양을 줄일 수 있다

단점

• 참조하려는 Page가 Invalid한 경우 Secondary Storage에 갔다와야하기에 Page Fault 발생

Page Fault

Process가 Page를 참조하였을 때 해당 Page가 할당 받은 Frame이 없는 경우

• Page Fault가 발생하여 Page Fault Handler 수행

Page Fault Handler가 수행하는 내용

• 새로운 Frame을 할당 받음

• Backing Storage에서 Page의 내용을 다시 Frame에 불러들인다

• Page Table을 재구성한다

• Process의 작업을 재시작한다

Working Set

1. Bounded-Buffer Problem

2. Readers and Writers Problem

• Solution 1
• Solustion 2

3. Dining Philosophers Problem

• Solution 1
• Solution 2

1. Bounded-Buffer Problem

N개의 Item을 삽입할 수 있는 Buffer에 여러 생산자(Producer)와 여러 소비자(Consumer)가 접근

생산자(Producer): 하나의 Item을 생산해 Buffer에 저장

• Race Condition 공유 데이터에 대해 여러 Process가 동시에 접근, 변경을 시도하는 상황 = Buffer에 대해 여러 Producer가 동시에 Item을 추가하려는 상황

소비자(Consumer): Buffer에서 하나의 Item을 가져옴

• 동작 조건 Buffer의 상태가 Empty면 대기

여러 생산자, 소비자 중 자신이 버퍼(Critical Section)에 접근하여 생산, 소비할 수 있는가?

produce과정과 consume과정은 모두 Buffer에 쓰는 과정이기에 (Write) 동시에 한 Process만이 Buffer에 접근해야 함.

Bounded-Buffer Problem 구현

Buffer의 구현

• 1차원 배열로 구현
• boolean buffer[n]; 으로 선언
• 초기화 buffer[0...n-1] = empty;

생산자 Operation

• Buffer 배열 중, empty인 index를 찾아 full로 바꿈 (0 -> 1)
• Buffer[m] = full;

소비자 Operation

• Buffer 배열 중, full인 index를 찾아 empty로 바꿈 (1 -> 0)
• Buffer[m] = empty;

Bounded-Buffer Problem Semaphore

문제 해결을 위한 세마포어

• Empty: Buffer 내에 저장할 공간이 있음을 표시 생산자의 진입을 관리

• Full: Buffer 내에 소비할 아이템이 있음을 표시 소비자의 진입을 관리

• Mutex: Buffer에 대한 접근을 관리 생산자, 소비자가 empty, full 세마포어를 진입한 경우, buffer의 상태 값을 변경하기 위한 세마포어 (버퍼에 쓸 공간이 있더라도 누가 이미 쓰고 있을 때를 위해서...)

초기값

Full = 0
Empty = n         //buffer에 empty인 entry가 n개 (Counting Sem) 
Mutex = 1

생산자 Process

do {
    ...
    produce an item in nextp
    ...
    P(empty);    // 버퍼에 적어도 하나의 공간이 생기기를 기다림
    P(mutex);    // Critical Section에 진입하기 위해 기다림
    ...
    add nextp to buffer
    ...
    V(mutex);    // Critical Section에서 빠져 나왔음을 알림
    V(full);    // 버퍼에 아이템이 있음을 알림
} while(True); 

empty는 n으로 init... => 버퍼의 n칸이 모두 비어있다.

소비자 Process

do {
    P(full);     // 버퍼에 적어도 하나의 아이템이 들어가기를 기다림
    P(mutex);
    remove an item from buffer to nextc
    ...
    V(mutex);
    V(empty);    // 버퍼에 하나의 빈 공간이 생겼음을 알림
    ...
    consume the item in nextc
    ...
} while(True);

full은 0으로 init...

2. Readers-Writers Problem

여러 Readers와 Writers가 하나의 공유 데이터를 읽거나 쓰기위해 접근

Readers - 공유 데이터를 읽음

• 여러 Reader는 동시에 Data를 읽을 수 있음

Writers - 공유 데이터에 씀

• Writer가 데이터를 수정하기 위해서는, Reader혹은 다른 Writer가 작업을 하고 있지 않아야 함

Readers-Writers Problem Solution 1

문제 해결을 위한 자료구조와 세마포어

• Int ReadCount: 버퍼에 현재 몇 개의 Reader가 접근중인지 표시
• Semaphore Wrt: Writers 사이의 동기화 관리
• Semaphore Mutex: Readcount와 wrt에의 접근이 원자적으로 수행됨을 보장하기 위한 세마포어

초기값

Mutex = 1 Wrt = 1 readcount = 0

Writer Process

P(wrt);        // entry section
    ...
    writing is performed
    ...
V(wrt);        // exit section

Reader Process

P(mutex);
    readcount++;
    if(readcount == 1)
        P(wrt);     // 어떤 writer도 수행되고 있지 않음을 판별

V(mutex);
    ...
    reading is performed
    ...
P(mutex);
    readcount--;
    if(readcount == 0)
        V(wrt);
V(mutex);

문제점

Writer의 Starvation

• Readcount == 0 일 때만 V(wrt)가 수행되어 P(wrt)로 대기하고 있던 Writer가 수행할 수 있음

• 첫 번째 Reader(Readcount == 1)가 P(wrt)만 통과하면, 다른 Reader들은 P(mutex)에 대한 P(mutex)만 기다리면 언제든지 수행할 수 있기 때문에 Writer와 상관없이 진입할 수 있음

• 여러 Reader들이 계속해서 진입할 경우, Readcount는 0까지 떨어지지 않을 수 있음

Writer의 Starvation을 예방하는 Solution이 존재함

• Writer process에 우선순위를 부여

Readers-Writers Problem Solution 2

Writer의 Starvation을 해결한 방법

3. Dining-Philosophers Problem

고전적인 Concurrency Method

5명의 철학자가 한 식탁에서 함께 식사를 하는 상황

젓가락이 5개뿐

• 자신의 바로 옆 젓가락만 집을 수 있음
• 두 젓가락을 모두 집어야 식사를 할 수 있음
• 식사를 하고 난 다음에야 두 젓가락을 모두 내려놓을 수 있음

Deadlock과 Starvation이 발생하는 경우

• 모두 자신의 오른쪽(혹은 왼쪽) 젓가락을 집었을 경우

Dining-Philosophers Problem Solution 1

단순히 젓가락을 집는 것에 대한 동기화를 부여하는 방법

• 모든 철학자가 자신의 왼쪽 또는 오른쪽 젓가락부터 집도록 한다.
• boolean waiting[n];

세마포어

• chopstick[5]: 각각의 젓가락에 대한 동기화 관리

초기값은 모두 1

철학자 Process

do {
    ...
    think
    ...
    P(chopstick[i]);                // 왼쪽을 잡을 수 있는가
    P(chopstick[(i + 1) % 5])        // 오른쪽을 잡을 수 있는가
    ...
    eat
    ...
    V(chopstick[i]);
    V(chopstick[(i + 1) % 5]);
    ...
} while(True);

동시에 chopstick을 잡으면 deadlock 발생 -> 모두가 왼쪽을 잡으면... (= P(chopstick[i]); 이후에...) 0번이 자신의 왼쪽 젓가락을 든 이후에 Deadlock에 빠졌다 (= 모든 철학자들(프로세스들)이 자신의 왼쪽 젓가락을 들었다)

Dining-Philosophers Problem 개선안

Deadlock의 해결 방안

• 한 번에 최대 4명의 철학자만 식탁에 앉도록 한다
• 젓가락의 상태를 미리 검사하여, 양 쪽의 젓가락이 모두 사용 가능할 때만 젓가락을 집도록 한다.
• 철학자에게 번호를 부여하여 홀수인 철학자는 왼쪽의 젓가락을, 짝수인 철학자는 오른쪽의 젓가락을 먼저 집도록 한다.

위의 해결방안들은 Starvation까지 해결해주지는 못함

• 각각의 방안에 대해 Starvation에 대한 고려를 추가할 수 있음 ex) 한 차례 굶은 철학자에게 우선권을 줌

Dining-Philosophers Problem Solution 2

양 쪽의 젓가락을 한꺼번에 집는 방법

• 젓가락의 상태를 미리 검사하여 양 쪽의 젓가락이 모두 사용할 때만 젓가락을 집도록 하는 방법

사용되는 자료구조

• State[5]: 각 철학자의 상태를 기록 (THINKING, HUNGRY, EATING)

문제 해결을 위한 세마포어

• mutex : 젓가락을 집거나 놓는 수행을 Critical Section으로 관리하기 위한 세마포어 초기값 = 1

• self[5] : 철학자 각각이 젓가락 두 개를 잡기를 기다리는 세마포어 초기값 = 모든 원소가 0 self[i] 의미는 철학자i가 HUNGRY 상태이더라도, 다른 젓가락 하나를 사용할 수 없을 경우 Waiting을 하기 위한 세마포어

철학자 Process

do {
    ...
       think
    ...
    take_chopsticks(i);
    ...
    eat
    ...
    put_chopsticks(i);
    ...
} while(True);

take_chopstick(int i){
    P(mutex);
    state[i] = HUNGRY;
    test(i);
    V(mutex);
    P(self[i]);
}

put_chopstick(int i){
    P(mutex);
    state[i] = THINKING;
    test(LEFT);
    test(RIGHT);
    V(mutex);
}

test(int i) {
    if(state[i] == HUNGRY &&            // 내가 배고프고 양쪽이 먹고 있지 않은(NOT EATING) 상태일 때
        state[LEFT] != EATING &&
        state[RIGHT] != EATING){
            state[i] = EATING;
            V(self[i]);
    }
}

take_chopstick() : Mutex를 통해 진입하여, test(i)를 통해 양쪽의 철학자 상태를 검사한 후, 자신이 먹을 차례를 기다린다.

put_chopstick() : Mutex를 통해 진입하여, test(LEFT), test(RIGHT)를 통해 양쪽의 철학자 상태를 검사한 후, 먹을 차례를 기다리는 철학자에게 signal을 보내준다.

test() : Test를 수행한 철학자(i)가 HUNGRY 상태이고, 양쪽의 철학자가 모두 젓가락을 집지 않은 상태 (NOT EATING)이면 take_chopsticks()에서 wait했던 자신의 세마포어 self[i]에 signal을 보내어 EAT으로 진행하도록 함

해설

Solution 2의 전략은 철학자 좌우 젓가락이 사용 가능할 때만 Critical Section에 진입함

• i 번째 철학자가 식사를 하기 위해서는 i-1 (LEFT)와 i+1 (RIGHT) 철학자가 EATING 상태가 아니어야 함

take_chopstick()와 put_chopstick()의 동작을 살펴보자

take_chopstick()

식사할 조건

• test() 함수 안에서 검사하는 LEFT와 RIGHT의 상태가 EATING이 아니어야 함

• test()를 만족하면, signal(self[i])에 의해 self[i]의 값은 1이 되므로, wait(self[i])에서 block되지 않고 식사를 진행한다.

self[i]의 초기 값은 0임

put_chopstick()

식사를 마치면, 좌 우 철학자의 test()함수를 실행한다.

• 이 때, 철학자 L과 R은 i에 의해 take_chopstick()에서 wait()함수에 의해 대기 중

• 철학자 i에 의해 실행한 test(LEFT) i와 LL의 상태를 확인

• 철학자 i에 의해 실행한 test(RIGHT) i와 RR의 상태를 확인

• 철학자 i가 식사중인 동안 LL 혹은 RR 철학자의 상태가 EATING으로 바뀐다 하더라도, test(LEFT)와 test(RIGHT)를 통해 signal을 수행하므로 동기화에 문제가 없다.

체크 요소들

Data Consistency가 확보되는지

Deadlock이 발생하는지

Starvation 가능성이 있는지

Concurrency를 얼마나 제공하는지

Withdrawing money form a bank account

• 친구들과 같이 돈을 관리하는 계좌에 30만원이 들어 있는 상황 A와 B가 서로 다른 ATM에 가서 동시에 10만원 씩 출금한다면?

int withdraw(account, amount){
    balance = get_balance(account);
    balance = balance - amount;
    put_balance(account, balance);

    return balance;
}

Sharing Resources

Local variables are NOT shared among threads

• Refer to data on the stack
• Each Thread has its own stack
• Never pass/share/store a pointer to a local variable on anoter thread's stack

공유 가능한 것들

• Global variables (전역변수) Stored in static data segment, accessible by any thread
• Dynamic objects (동적 할당된 객체) Stored in heap, shared through the pointers

각각의 Thread는 ($T_1, T_2, T_3$)는 자신의 Register, Stack을 가지고 있고 다른 Thread의 Stack에는 접근할 수 없다. Code, Data, File을 공유한다.

Race Condition

Concurrency leads to non-deterministic results!

• Program results vary from run to run even with same inputs, depending on timing

공유 데이터에 대한 동시 접근은 데이터의 일관성(Consistency)를 해치는 결과를 낳을 수 있음

• Race Condition 공유 데이터에 대해 여러 Process가 동시에 접근, 변경을 시도하는 상황

데이터 일관성을 유지하기 위해서는 서로 협력하여 수행되는 Process들(Cooperating Process)이 순차적으로 수행하게 만드는 기법이 필요함

• Process 간의 동기화 (Process Synchronization)

• Synchronization restricts the concurrency (모순적이게도 Concurrency를 해칠 수 밖에...)

• Scheduling is not under programmer's control

Critical Section

Critical Section

• 여러 Process들이 공유하는 데이터에 접근하는 Code 영역
• ** 한 번에 오직 하나의 Proecess만이 Critical Section에 진입해야 함**

  Critical Section을 가지는 Process의 Modeling

  

Critical Section 해결의 조건들

Critical Section 문제를 해결하는 Algorithm은 아래와 같은 세 가지 조건을 만족해야 함

• Mutual Exclusion (상호 배제) 만약 Process A가 Critical Section에 진입해 있다면, 다른 모든 Process는 진입할 수 없어야 함

• Progress (진행) 만약 어떤 Process도 Critical Section내에 있지 않고, Critical Section에 진입하려는 Process가 존재한다면, Remainder Section에서 실행 중이 아닌 Process들 (= 진입하려는 Process들) 만이 누가 진입할지 결정할 수 있어야 함 -결정은 무한히 연기될 수 없음 (Deadlock-free)

• Bounded Waiting Process가 Critical Section에 진입할 때까지 걸리는 시간에 Limit이 존재해야 함(Starvation-free)

두 Process를 위한 Algorithm

Shared Variables:

• int turn = 0; 으로 초기화
• turn = 0일 때,

만족 조건 : Mutual Exclusion 불만족 조건 : Progress, Bounded Waiting

turn=0으로 초기화 된 것이 문제이다. 프로세스 $P_0$가 언제 실행될지 모르는 상황에서 $P_1$이 실행되면은 $P_1$은 무한 루프를 돌고 있다. (Progress, Bounded Waiting 불만족)

다른 알고리즘(Flag)

Shared Variables:

• boolean flag[2]; flag[0] = flag[1] = flase로 초기화

• flag[0] = true일 때, $P_0$가 critical section에 진입 가능

• flag[1] = true일 때, $P_1$가 critical section에 진입 가능

  만족 조건 : Mutual Exclusion 불만족 조건 : Progress, Bounded Waiting

그림과 같이 1,2,3,4 순서대로 코드가 실행되버리면, flag[0]와 flag[1]이 모두 true의 값을 가지게 되고 두 프로세스는 무한 루프에 빠져버려 진행되지 않는다.

Peterson Solution

Shared Variables:

• int turn;
• boolean flag[2]; flag[0] = flag[1] = flase로 초기화

flag와 turn을 모두 사용하는 방식이지만, turn을 0으로 초기화하지 않음.

만족 조건 : Mutual Exclusion, Progress, Bounded Waiting

• 두 Process가 동시에 수행되더라도, Turn 값에 의하여 결정됨

Peterson Solution의 한계

3개 이상의 Process에서는 구현이 쉽지 않음.

하드웨어로 처리하면 알고리즘이 매우 간단하게 됨

간단한 방법

Critical Section에 들어가면서 Interrupt를 Disable함

User Program이 Interrupt를 Control하는 것은 바람직하지 않음

Scalable 하지 않음

• Process의 숫자가 많아 질 때 문제가 생길 소지

  동기화를 위한 Instruction이 도입됨

Synchronization Instruction

CPU에서 지원하여 원자적(Atomic)으로 수행되는 명령어(Instruction)를 이용

• 원자적이란?
• *명령어가 수행되는 동안 방해 받지 않음(= Uninterruptible)
• *

  Test and Set 명령어

• 아래의 코드는 Atomic하게 동작함

  boolean TestAndSet(boolean *target){
    boolean rv = *target;
    *target = true;
    return rv;
  }

  Mutual Exclusion with Test-and-set

  Shared Variables:

• boolean lock = false;

Process $P_i$

do {
    while(TestAndSet(&lock));
        critical section
    lock = false;
        remainder section
}

critical section에 들어오면서 lock을 true로 변경해줌 + return값은 아직 false

Mutual Exclusion with Swap

Shared Variables:

• boolean lock;
• boolean waiting[n];

Process $P_i$

do {
    waiting[i] = true;
    while(waiting[i] == true)
        swap(&lock, &waiting[i]);
            critical section
    lock = false;
        remainder section
}

H/W에서 제공하는 Instruction인 TestAndSet()과swap() 연산은 Atomic하기 때문에, Mutual Exclusion과 Progress(Deadlock-free)를 만족하지만, Bounded Waiting 같은 조건은 User Program에서 제공해야 한다.

# Example : Bounded Waiting Solution

// Shared Data
boolean waiting[n];
boolean lock; 

do {
    waiting[i] = TRUE;
    key = TRUE;
    while(waiting[i] && key)
        key = TestAndSet(&lock);
    waiting[i] = FALSE;

    // critical section

    j = (i + 1) % n;                // i 이후의 프로세스들부터 보겠다.
    while((j != i) && !waiting[j])  // 순회하면서 waiting = TRUE인 프로세스를 찾음
        j = (j + 1) % n;            // 순차적으로 다음 프로세스를 본다
    if (j == i)                       // 대기중인 프로세스가 없다면, lock을 해제한다
        lock = FALSE;
    else
        waiting[j] = FALSE;            // 대기중인 프로세스가 있다면 해당 프로세스를 critical section으로...

    // remainder section

} while (TRUE);

Semaphores

세마포어: 두 개의 원자적 연산을 가지는 정수 변수

• 원자적인 연산:
  • Wait() 또는 P()
  • Signal() 또는 V() 이 변수는 2개의 원자적인 연산(Atomic Operation)에 의해서만 접근됨

P는 Critical Section 들어가기 전에, V는 나와서 수행함

P와 V연산은 서로 독립적으로, 그리고 원자적으로 수행됨

• 하나의 Process가 P를 수행하여 세마포어의 값을 수정하는 동안, 다른 Process에서 P나 V를 수행하여 같은 세마포어의 값을 수정하지 못함

Semaphores의 구현 - Busy Waiting

Busy Waiting 이용 (Original)

P(Sem) {
    while (Sem <= 0);
    Sem = Sem - 1;
}

S(Sem) {
    S = S + 1;
}

Busy Waiting은 Critical Section에 진입할 조건이 될 때까지 Loop를 돌며 기다린다.

• 단점 CPU Cycle을 낭비할 수 있음 대기 중인 Process 중에서 누가 Critical Section에 진입할지 결정할 수 없음 (Bounded Waiting (= Starvation)

Semaphores의 구현 - Sleep Queue

Sleep Queue를 이용한 구현

• Busy Waiting 방식의 CPU Cycle을 낭비하는 문제를 해결

• Semaphore의 자료구조에 Sleep Queue를 추가하여, 대기 중인 Process를 관리

  • Semaphore의 값이 양수가 되어 Critical Section에 진입이 가능하게 되면, Sleep Queue에서 대기 중인 Process를 깨워 실행시킴

typedef struct {
    int value;                    // 세마포어 값
    struct process *list;        // 세마포어를 대기하는 프로세스의 sleep queue
} semaphore;

P(semaphore *S){
    S -> value--;
    if (S -> value < 0){
        add this process to S -> list;    // 프로세스를 sleep queue에 삽입
        sleep();
    }
}

V(semaphore *S){
    S -> value++;
    if (S -> value <= 0)
        remove a process P from S -> list;  // 프로세스를 sleep queue에서 꺼내온 후,
        wakeup(P);                            // 실행
    }
}

Semaphores의 종류

2가지의 Semaphore

• Counting Semaphore

  • Semaphore 값은 범위가 정해져 있지 않음
  • 초기값은 가능한 자원의 수로 정해짐

• Binary Semaphore

  • Semaphore value가 가질 수 있는 값은 0과 1
  • Counting Semaphore보다 구현이 간단함

Binary Semaphore를 이용하여 Counting Semaphore를 구현할 수 있음

Binary Semaphore는 TestAndSet()과 같은 Hardware의 도움을 받아서 구현할 수 있음

H/W Instruction(TestAndSet) -> Binary Sem -> Counting Sem

Binary Semaphore의 구현

TestAndSet()을 이용하여 구현

Semaphore S : 현재 Critical Section에 진입한 Process가 있는지 나타냄 (True or False)

P(S)

• while (test_and_set(&S)); S의 값이 리턴되고, S는 true로 바뀜

V(S)

• S = false; 진입한 Process가 없음을 나타내어 wait()에서 대기 중인 Process를 진입 가능하도록 함

Counting Semaphore의 구현

Binary Semaphore를 이용하여 구현

• Counting Semaphore를 CS라 하고, value는 C = 0이라 하자.
• 2개의 Binary Semaphore S1, S2를 이용 (S1 for Mutex, S2 for delay)
• S1 = 1, S2 = 0 으로 초기화 (C가 양수라고 가정)

# Wait Operation (P)
P(S1);
C--;
if (C < 0){
    V(S1);
    P(S2);
}
else
    V(S1);


# Signal Operation (V)
P(S1);
C++;
if (C <= 0) {
    V(S2);
}
V(S1);

Semaphore의 구현

Kernel이 Single Thread인 경우

• P/V를 System Call로
• kernel내에서 처리하여 Semaphore 동작을 구현함
• Kernel내의 수행이 Non Preemptive이므로, Kernel에 들어간 것이 Critical Section에 들어간 것임

Kernel이 Multithread인 경우

• P/V를 System Call로
• Kernel 내에서 별도로 동기화를 진행

Semaphore의 단점

Deadlock이 발생할 가능성이 존재함

P와 V의 연산이 분리되어 있기 때문에 잘못 사용할 경우에 대책이 없음

• P(); -> Critical Section -> P(); Critical Section 후에 Lock을 풀어주는 V()가 없으므로, 한 Process가 Critical Section에 진입하면, 나올 수 없다. (다른 Process들이 Critical Section에 진입 못하므로 Deadlock 발생)

• V(); -> Critical Section -> P(); Critical Section 전에 Lock을 걸어주는 P()가 없으므로, 여러 Process가 동시에 Critical Section에 진입 할 수 있으므로, Mutual Exclusion을 보장 못함

Deadlock

Deadlock

• 두 개 이상의 Process들이 끝없이 이벤트를 기다리고 있는 상황
• 그 이벤트는 기다리고 있는 Process만이 발생 시킬 수 있는 것

Monitor

High-level 언어에서의 동기화 방법

• Java의 Thread에서 동기화를 위한 방법으로 Monitor가 사용됨

한 순간에 하나의 Process만 Monitor에서 할동하도록 보장

• 공유데이터(필드값)와 공유데이터를 접근하는 코드(함수)를 하나의 모니터(객체)에 구성

Application은 Semaphore와 같이 P와 V연산에 대한 고려 없이 Procedure를 호출하는 것 만으로 동기화를 해결할 수 있음

• Procgrammer는 동기화 제약 조건(P, V)을 명시적으로 코드화 할 필요 없음

Process - Abstraction for

• Execution Unit - Scheduling 단위
• Protection Domain - 소유하고 있는 자원에 대한 보호

Program과 Process 관계

• Executing program with a single thread of control
• 지금까지의 Process 개념 = 하나의 실행 흐름을 갖고 실행 중인 Program*

1개의 실행 흐름을 여러개로 만든다면??

Thread란 무엇인가?

정의

• Execution Unit
• ** Process 내의 실행 흐름**
• Process 보다 작은 단위 (Finer Grain)
• Process가 제공한 Protection Domain은 없음 (하나의 Process내의 Thread간 에는...)

동기

• 하나의 Process에는 하나의 Control만이 존재하기 때문에, 한 번에 하나의 일 만을 처리
• Process에서 할 작업을 여러 개로 나눈 후에 각각을 Thread화 한다면, 병렬적으로 작업을 완수 할 수 있음.
• Cooperative Process와의 차이점
  • Cooperative Process는 IPC가 필요 - 비용이 많이 듦
  • Process 사이의 Context Swithching 비용
  • Process 내에서 Cooperation하는 Thread를 만든다면
  • Process보다 적은 비용으로 Cooperative Process가 하는 일을 동일하게 수행 가능*

Process를 생성하는 것 보다, Thread를 생성하는 것이 더 적은 비용..(IPC, Context Switching)

Theread와 CPU Utilization

• Thread의 수가 증가할수록 CPU의 Utilization이 증가 임계값을 넘어가면 다시 감소 -> Thread Switching 비용이 증가함.

• CPU가 많은 System일 수록 Thread를 이용하는 것이 유리 Multi-processor, 즉 CPU의 수가 많을 수록 한 Process에서 여러 Thread를 Parallel하게 실행하는 것이 유리.

Process와 Threads

Process

• Single Thread process와 동일

• Process 간의 Memory는 독립적이므로, 서로의 영역에 접근하기 어려움 IPC나 Shared Memory를 사용한다.

• Process간의 Switching 비용이 큼 (상대적으로 Heavy Weight)

Threads

• 하나의 Process 안에 여러개의 Thread가 존재 (Multi Thread process와 동일)

• Process의 Code 영역과 Data 영역은 Thread간에 공유

• Thread들은 같은 Memory 영역을 사용하므로, Thread간 Switching 비용이 적음

Thread의 구성 요소

Thread는 Process내의 하나의 실행 흐름이므로, 실행과 관련된 자료 구조가 필요

• Thread ID : Thread 식별자

• Program Counter : 현재 실행중인 Instruction 주소

• Register Set : CPU의 Register 값들

• Stack : Process보다 Thread의 고유 정보 수가 적기 때문에 Thread Switching 비용이 적음

동일한 Process 내에 있는 다른 Thread와 공유하는 것

• Code : Program의 Code Section
• Data : Process의 Data Section
• File : Process에서 Open한 File

각 Thread 간에는 code, data, files 부분은 공유하고, 각 Thread는 registers와 stack을 가지고 있음을 알 수 있다.

Process vs. Thread

Multi-Process 환경에 비해서, Multi-Thread가 메모리 관점에서 더 이득임을 알 수 있다.

Multi-Threaded Program의 장점

Responsiveness

• Program의 어느 부분을 담당하는 Thread가 Block되거나 시간이 걸리는 작업을 하더라도, 다른 Thread들은 실행되고 있기 때문에 User의 입장에서는 그 Program이 Interactive하다고 볼 수 있음

Resource Sharing

• Thread들 간에는 Process의 Memory와 다른 자원들을 공유

Economy

• Thread들은 하나의 Process Memory 영역에서 실행하기 때문에 새로운 Process를 생성하는 것보다 Thread를 생성하는 것이 비용이 적게 들어감

Scalability

• 여러 개의 Thread가 각각 다른 Processor에서 동시에 실행이 가능

Multicore Programming

최근 Processor 설계 동향은 하나의 Chip에 여러 개의 Computing Core를 탑재 -> Multicore Processor

Multithread Programming은 Multicore 시스템에서도 효율적임

• Multicore Processor는 운영체제에서 **각각의 Core를 하나의 Processor로 인식하고 Scheduling
• 각각의 Core에 Thread를 할당하여 실행 가능
• Multiple Processor가 달린 Multicore는 Cache를 공유하기 때문에 Data, Code, 등 Process의 자원을 공유하는 Multithreaded Programming에 보다 효율적임

User and Kernel Threads

Thread를 지원하는 주체에 따라 나뉨(User vs Kernel)

User Threads

• Kernel 영역 위에서 지원되며, 일반적으로 User Level의 Library를 통해 구현됨

• Library에서 Thread를 생성, Scheduling과 관련된 관리를 해줌

• 장점 동일한 Memory영역에서 Thread가 생성, 관리되므로 이에 대한 속도가 빠르다.

• 단점 여러 개의 User Thread 중 하나의 Thread가 System Call 요청으로 Block이 된다면, 나머지 모든 Thread 역시 Block 된다.

-> Kernel은 여러 User Thread들을 하나의 Process로 간주하기 때문

Kernel Thread

• 운영체제에서 Thread를 지원

• Kernel 영역에서 Thread의 생성, Scheduling 등을 관리

• 장점

• Thread가 System Call을 호출하여 Block이 되면, Kernel은 다른 Thread를 실행함으로써 전체적인 Thread Blocking이 없음* Multiprocessor 환경에서 Kernel이 여러 개의 Thread를 다른 Processor에 할당할 수 있음

• 단점 User Thread보다 생성 및 관리가 느림

Mapping of User & Kernel Thread

Many-to-One

• Thread 관리는 User Level에서 이루어짐(=User-level Threading)

• ** 여러 개의 User Level Thread들이 하나의 Kernel Thread로 Mapping됨**

• Kernel Thread를 지원하지 못하는 System에서 사용됨

• 한계점

• 한번에 하나의 Thread만 Kernel에 접근 가능*

  • 하나의 Thread가 Kernel에 접근 (System Call)하면, 나머지 Thread들은 대기해야 함
  • 진정한 Concurrency는 지원하지 못함
  • 동시에 여러 개의 Thread가 System Call 사용 불가

Kernel의 입장에서 여러 개의 Thread는 하나의 Process이기 때문에 Multiprocessor더라도 여러 개의 Processor에서 동시에 수행 불가능

One-to-One

• 각각의 User Thread를 kernel Thread로 Mapping

• User Thread가 생성되면, 그에 따른 Kernel Thread가 생성

• Many-to-One 방법에서 문제가 되었던, System Call 호출 시 다른 Thread들이 Block되는 문제를 해결

• 여러 개의 Thread를 Multiprocessor에서 동시에 수행할 수 있음

• 한계점

• Kernel Thread도 한정된 자원이기 때문에, 무한정으로 생성할 수 없음* Thread를 생성, 사용하려 할 때 그 개수에 대한 고려가 필요

Many-to-Many

• 여러 개의 User Thread를 여러 개의 Kernel Thread로 Mapping

• Many-to-One과 One-to-One Model의 문제점을 해결

• Kernel Thread는 생성된 User Thread와 같거나, 적은 수 만큼만 생성이 되어 적절히 Scheduling됨 One-to-One처럼 사용할 Thread의 수에 대해 고민할 필요가 없음 Many-to-One처럼 Thread가 System Call을 사용할 경우, 다른 Thread들이 Block되는 현상에 대해 걱정할 필요가 없음.

• Kernel은 적절히 User Thread와 Kernel Thread 사이의 Mapping을 조절하여, 위와 같은 장점을 보장할 수 있음

Thread로 인한 운영체제의 변화

Process 기반의 운영체제 System Call

• Process 관련 System Call Semantics는 Process 기준으로 작성됨
• Thread의 개념에 대한 고려 필요
• fork(), exec() : Thread 지원을 위해서 변화가 필요*
• Thread 종료 문제 : Multi-thread일 경우, 함께 일하는 Thread의 종료는 Process보다 복잡해짐*

Thread Issues : Creation

Fork()

Thread에서 fork() 요청 시, 모든 thread를 가지고 있는 Process를 만들 것인지, fork()를 요청한 thread만을 복사한 Process를 만들 것인지.

Exec()

fork()를 하여 모든 Thread를 복사한 경우 exec()을 수행하면 모든 Thread들은 새로운 Program으로 교체가 됨

fork()를 하고 exec()을 수행할 경우 fork()를 요청한 Thread만이 복사되는 것이 더 바람직함 그러나 fork()를 하고 exec()를 수행하지 않는 경우에는 모든 Thread의 복사가 필요하기도 함

Thread Issues : Cancellation

• Thread Cancellation : Thread의 작업이 끝나기 전에 외부에서 작업을 중지시키는 것

• 하나의 Thread에서 중지 명령이 결국은 다른 Thread의 모든 작업을 중지시켜야 하는 경우

• 자원이 Thread에게 할당된 경우 Cancellation의 문제 System의 자원을 사용하고 있는 Thread가 중지 될 경우 할당된 자원을 함부로 해제할 수 없음-다른 Thread가 그 자원을 사용하고 있을지도 모르기 때문

Thread Issues : Thread Pools

• Thread가 자주 생성되고 제거되는 상황에서 새로이 Thread를 만드는 시간이 실제 Thread가 동작하는 시간보다 긴 경우가 있음

Pool을 만들어 정해진 수 만큼의 Thread를 만든 후 Pool에 할당

Thread Issues : Thread IPC

• Multithreaded Programming에서는 Thread간 통신이 필요함
• Thread간 IPC 구현은?
• 동일한 Process 내의 Thread 간 통신은, Shared Memory가 효율적임* (Thread들은 같은 Process의 Data영역을 공유하므로)
• 결국 IPC가 최소화 됨
• 다른 Process에 존재하는 다른 Thread와의 통신은?
• Process의 경우와 비슷한 성능을 보임* 이런 통신이 빈번하다면, Program 설계의 잘못

Inter Process Communication (IPC)

• Process들 간에 데이터 및 정보를 주고 받기 위한 Mechanism
• Kernel에서 IPC를 위한 도구를 제공
• System Call의 형태로* Process에게 제공됨

IPC의 필요성

• Process 협력 모델(Cooperating Process Model)을 구현하기 위해 IPC가 반드시 필요함 실행 중인 Process는 협력하는 다른 Process의 영향을 받음

IPC의 두 가지 모델 - Shared memory

Shared Memory

• Process의 특정 Memory 영역을 공유
• 공유한 Memory 영역에 읽기 / 쓰기를 통해서 통신을 수행
• 응용 프로그램 레벨에서 통신 기능 제공
• 공유 메모리가 설정되면, 그 이후의 통신은 Kernel의 관여 없이* 진행 가능

IPC의 두 가지 모델 - Message Passing

Message Passing

• Process간 Memory 공유 없이 동작 가능
• 고정길이 메시지, 가변길이 메시지를 송/수신자끼리 주고 받음
• Kernel을 통한 메시지 통신 기능을 제공
• 활용 예) 클라이언트-서버 방식의 통신
• 구현 IPC Pipe, Message Queue, Socket

IPC의 기본 동작

Shared Memory 방식

• Read and Write
• Process들의 주소 공간의 일부를 공유 메모리로 설정하여, 프로그램에서 바로 접근

Message Passing 방식

• Send and Receive
• Kernel을 경유하여 Message 전송
• Kernel에서 데이터를 버퍼링
• 문맥전환에 연관됨

IPC에서 동기화의 필요성

Shared Memory 방식 - 부가적인 방법이 필요

• Memory 영역에 대한 동시적인 접근을 제어하기 위한 방법이 필요
• 접근 제어 방식은 Locking이나 세마포어(Semaphore)방법이 있음

Message Passing 방식 - Kernel이 동기화 제공

• Send와 Receive와 같은 연산에 대해서는 Kernel이 동기화
• Send와 Receive를 수행할 때에는 Program에서 동기화에 대한 고려 없이 사용 가능

Pipe

하나의 Process가 다른 Process로 데이터를 직접 전달하는 방법

• 데이터는 한 쪽 방향으로만 이동함. 따라서 양방향 통신을 위해서는 두 개의 Pipe가 필요(Half duplex)
• 1대1의 의사소통만이 가능
• 보내진 순서로만 받음
• 용량 제한이 있기 때문에, Pipe가 꽉 차면 더 이상 쓸 수 없음

#include <stdio.h>
#include <unistd.h>
#incldue <sys/types.h>
#define MAXLINE 4096

int main(void){
    int n, fd[2];
    pid_t pid;
    char line[MAXLINE];

    // pipe 생성
    if (pipe(fd) < 0) {
        perror("pipe error");
        exit(-1);
    }

    // 자식 프로세스 생성
    if ((pid = fork()) < 0) {
        perror("fork error");
        exit(-1);
    }
    // 부모 프로세스에서는 write만 한다.(예제임)
    else if(pid > 0) {
        /* parent */
        close(fd[0]);  // read pipe 닫기
        write(fd[1], "hello, world.\n", 14);
        waitpid(pid, NULL, NULL);
    }
    // 자식 프로세스에서는 read만 한다.
    else{
        /* child */
        close(fd[1]);  // write pipe 닫기
        n = read(fd[0], line, MAXLINE);
        write(STDOUT_FILENO, line, n);
    }
    fflush(stdout);
    exit(0);
}

Signal

특정 Process에게 Kernel을 통해 Event를 전달하는 방법

• 송신 Process: 여러 신호 중 하나를 특정 Process에 보냄. 이 동작은 수신할 Process의 상태에 무관하게 수행(=비동기적이다)

• 수신 Process: 신호 종류에 따라 신호 처리 방법을 지정 가능 무시 단순히 신호를 붙잡아 둠 특정 처리 루틴(Signal handler)를 두어 처리

• 비동기적인 동작 Process A가 Signal을 Process B에게 보내더라도, Signal처리는 Process B가 Scheduling 되어야 가능함

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

// singal Handler
void SignalHandlerChild(int signo){
    printf("signal handler\n");
    fflush(stdout);
}

int main(void) {
    pid_t pid;
    struct sigaction act_child;

    act_child.sa_handler = SignalHandlerChild;
    act_child.sa_flags = 0;
    sigemptyset(&act_child.sa_mask);
    sigaction(SIGUSR1, &act_child, 0);

    switch(pid == fork()){
    case -1:
        perror("fork failed");
        exit(-1);
    case 0:
        sigpause(SIGUSR1);     // signal을 기다리는 중
        return 0;
    default:
        sleep(3);
        kill(pid, SIGUSR1);    // 해당 pid에 시그널 전송
        waitpid(pid, 0,0);
    }
    return 0;
}

// sleep(3); 이후에 출력됨

Shared Memory

두 개 이상의 Process들이 하나의 Memory 영역을 공유하여 통신하는 방법

• Memory의 직접 사용으로 빠르고 자유로운 통신 가능
• 둘 이상의 Process가 동시에 Memory를 변경하지 않도록, Process간의 동기화가 필요함

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <sys/wait.h>

#define SHM_SIZE 1024

void ChildRun(int shmid);

int main(int argc, char **argv){
    int shmId, pid;
    char *ptrShm;

    // shared Memory 생성
    if ((shmID = shmget(IPC_PRIVATE, SHM_SIZE, SHM_R | SHM_W)) < 0 ) {
        perror("shmget error");
        exit(-1);
    }

    // shared Memory attach (shm 주소 포인팅)
    if ((ptrShm = shmat(shmId, 0, 0)) == (void *)-1) {
        perror("shmat error");
        exit(-1);
    }

    ptrShm[0] = 11;
    ptrShm[1] = 22;

    printf("Parent : %d, %d\n", ptrShm[0], ptrShm[1]);

    // 자식 프로세스 생성
    switch (pid = fork()){
    case 0:
        ChildRun(shmId);
        return 0;

    case -1:
        perror("fork error");
        exit(-1);

    default:
        break;
    }

    waitpid(pid, NULL, 0);

    printf("Parent : %d, %d\n", ptrShm[0], ptrShm[1]);

    if (shmdt(ptrShm) < 0) {
        perror("shmctl error");
        exit(-1);
    }

    if (shmctl(shmId, IPC_RMID, 0) < 0) {
        perror("shmctl error");
        exit(-1);
    }

    return 0;
}

void ChildRun(int shmid){
    int shmId;
    char *ptrShm;

    shmId = shmid;
    if((ptrShm = shmat(shmId, 0, 0)) == (void*)-1) {
        perror("shmat error");
        exit(-1);
    }

    printf("Child : %d, %d\n", ptrShm[0], ptrShm[1]);
    printf("Child : Modify value.\n");
    ptrShm[0] = 33;
    ptrShm[1] = 44;

    if (shmdt(ptrShm) < 0){
        perror("shmctl error");
        exit(-1);
    }
}

Message Queue

고정된 크기를 갖는 Message의 연결 리스트(Linked List)를 이용하여 통신을 하는 방법

• Message 단위의 통신 Message의 형태는 사용자가 정의하여 사용

• 여러 Process가 동시에 접근 가능(동기화 필요)

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <stdbool.h>
#include <errno.h>
#include <unistd.h>
#include <sys/type.h>
#include <sys/ipc.h>
#include <sys/msg.h>
#include <sys/wait.h>

typedef struct _MSG {
    long type;
    char message[256];
} MSG, *PMSG, **PPMSG;

#define MSG_ sizeof(MSG)

int main(void) {
    pid_t pid;
    key_t msg_id;
    MSG msg;

    if (-1 == (msg_id = msgget(IPC_PRIVATE, 0660 | IPC_CREAT))) {
        perror("msgget failed");
        exit(1);
    }

    switch(pid = fork()){
    case -1:
        perror("fork failed");
        exit(-1);
    case 0:
        msg.type = 1;
        strcpy(msg.message, "Hello, world.");
        msgsnd(msg_id, &msg, MSG_ - sizeof(long), 0);
        return 0;

    default:
        waitpid(pid, 0, 0);
        memset( &msg, 0, MSG_);
        msgrcv(msg_id, &msg, MSG_ -sizeof(long), 1, 0);

        printf("PARENT - message from child : %s\n", msg.message);
        fflush(stdout);
    }

    if (-1 == msgctl(msg_id, IPC_RMID, 0)) {
        perror("msgctl failed");
        exit(-1);
    }

    return 0;
}

Socket

Socket의 정의

• An end-point for communication

Port를 이용하여 통신하는데 사용됨

• Port는 운영체제가 제공하는 Abstraction임.
• Port 번호를 이용하여 통신하려는 상대 Process의 Socket을 찾아감

다른 IPC와 달리 Process의 위치에 Independent

• Local 또는 Remote
• Port의 도움으로 가능 Local의 경우, Port 번호만으로 식별 Remote의 경우, IP 주소 + Port 번호 조합으로 식별

연결(Connection)의 Semantics를 정할 수 있음

• Reliable(TCP) / Unreliable(UDP)

Socket의 특성

Process Independent

• Port를 사용하기 때문에 Machine Boundary와 관계 없음
• E.g., Port로 여러 Web Browser를 생성 Remote Machine은 Local Machine의 Port만 보임(Socket은 보이지 않음)

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
void ErrorHandling(char* message);
int main(void)
{
    int port = 9999, acceptState, hServSock, hClntSock;
    struct sockaddr_in servAddr, clntAddr;
    char buffer[20], message[20] = "message from server";
    socklen_t szClntAddr;
    pid_t pid;
    switch (pid = fork()) {
    case -1:
        perror("fork failed ");
        exit (-1);
    case 0:
        sleep (1);
        hClntSock = socket(AF_INET, SOCK_STREAM, 0);
        clntAddr.sin_family = AF_INET;
        clntAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
        clntAddr.sin_port = htons(port);
        szClntAddr = sizeof(clntAddr);
        if (connect(hClntSock, (struct sockaddr *)&clntAddr, szClntAddr) < 0){
            perror("<Child> Connect error: ");
            break;
        }
        printf("<Child> connect port: %d!\n", port);
        recv(hClntSock, buffer, 20, 0);
        printf ("<Child> %s\n", buffer);
        close(hClntSock);
        break;

    default:
        printf("<Parent> binding port: %d...\n", port);
        hServSock = socket(PF_INET, SOCK_STREAM, 0);
        if (hServSock == -1)
            ErrorHandling("<Parent> socket() error");
        memset(&servAddr, 0x00, sizeof(servAddr));
        servAddr.sin_family = AF_INET;
        servAddr.sin_addr.s_addr = htonl(INADDR_ANY);
        servAddr.sin_port = htons(port);
        if (bind(hServSock, (struct sockaddr*)&servAddr, sizeof(servAddr)) < 0 )   ErrorHandling("<Parent> bind() error");
        printf("<Parent> listening port: %d...\n", port);
        if (listen(hServSock, 1) < 0)
            ErrorHandling("<Parent> listen() error");
        printf("<Parent> accepting...\n");
        while (1) {
            szClntAddr = sizeof(clntAddr);
            hClntSock = accept(hServSock, (struct sockaddr*)&clntAddr, &szClntAddr);
            if (hClntSock <0) continue;
            printf("<Parent> accept port: %d!\n", port);
            acceptState = 1; //connected;
            if (acceptState == 1) break;
        }
        send(hClntSock, message, strlen(message)+1, 0);
        sleep (1);
          close(hServSock);
    }
    return 0;
}
void ErrorHandling(char* message)
{
    fputs(message, stderr);
    fputc('\n', stderr);
    exit(1);
}

Scheduling이란 무엇인가?

CPU Scheduling

• 어떻게 Process에게 CPU를 할당할 것인가 Multiprogramming에 기반함 - Memory 내의 실행 준비된(Ready State)의 Process들 가운데 하나에게 CPU를 할당함

CPU Scheduling의 목표

• CPU 사용률과 처리량의 최대화

Process 수행 사이클의 구성

CPU-I/O Burst Cycle

• CPU Burst : CPU로 연산을 수행하는 시간
• I/O Burst : I/O 처리를 위해 기다리는 시간
• 일반적인 프로세스는 두 Burst를 번갈아 가면 수행함

Process분류에 따른 CPU Burst의 특징

• CPU-Bound Process: 짧은 주기의 긴 CPU Burst (=> 자주자주 긴 연산 시간이 소요됨)

• I/O-Bound Process: 긴 주기의 짧은 CPU Burst (= Memory-Bound Process) (=> 짧은 연산이 소요됨)

• 어떤 종류의 Process가 많은지에 따라 스케줄링 기법의 효율성이 달라짐

Scheduling의 종류

CPU Scheduling의 결정은 다음 시점에 따라 이루어짐

• 1. Running에서 Waiting 상태로
• 2. Running에서 Ready 상태로
• 3. Terminated
• 4. Ready에서 Running 상태로

비선점형 스케줄링 (Non-preemptive Scheduling)

• 1(I/O, event 발생)과 4(새롭게 CPU를 할당 받는...)의 상황에서만 수행되는 Scheduling기법
• Multiprogramming의 기본 Scheduling - OS가 강제로 CPU 사용을 해제하지 못함 => I/O나 Event발생으로 인해 프로세스가 CPU를 포기해줘야지 다른 프로세스에게 CPU를 할당해 줄 수 있다.

선점형 스케줄링 (Preemtive Scheduling)

• 그 외의 다른 Scheduling 기법
• OS가 현재 CPU를 사용하고 있는 Process의 수행을 정지할 수 있음 - 2번으로의 상태 변이가 일어남 => 프로세스가 실행 중인데, OS가 강제적으로 프로세스로부터 CPU의 할당을 해제함.

Scheduling Criteria

CPU 사용률(CPU Utilization)

• 전체 시스템 시간 중 CPU가 작업을 처리하는 시간의 비율

  처리량 (Throughput)

• CPU가 단위 시간 당 처리하는 프로세스의 개수

  응답 시간 (Response Time)

• Interactive System에서 요청 후 첫 응답이 올 때까지의 시간

  대기 시간 (Waiting Time)

• Process가 Ready Queue 내에서 대기하는 시간의 총합

  Turnaround Time

• Process가 시작해서 끝날 때까지 걸리는 시간

이상적인 스케줄러

• 최대의 CPU Utilization
• 최대의 Throughput
• 최소의 Response Time
• 최소의 Watiting Time

  모든 조건을 만족 시키는 Scheduler를 만드는 것은 현실적으로 불가능

  시스템의 용도에 따른 요구사항이 달라짐

• 슈퍼 컴퓨터 : CPU 사용률
• 개인용 컴퓨터 : 응답시간
• 워크스테이션 : 처리량

Scheduling Algorithms

First-Come, First-Served (FCFS) Scheduling

먼저 CPU 할당을 요청한 Process에 CPU를 먼저 할당한다.

• FIFO Queue를 사용하여 간단하게 구현 가능
• 비선점형 스케줄링

대기 시간 : $P_1 = 0, P_2 = 24, P_3 = 27$ 평균 대기 시간 : (0 + 24 + 27) / 3 = 17

대기 시간 : $P_1 = 6, P_2 = 0, P_3 = 3$ 평균 대기 시간 : (6 + 0 + 3) / 3 = 3 (1)의 경우 보다 짧은 대기 시간을 가짐

결론 : FCFS는 작업의 수행 순서에 따라 대기 시간이 변할 수 있다.

Shortest-Job-First (SJF) Scheduling

다음 CPU Burst Time이 가장 짧은 Process에 CPU를 먼저 할당한다.

• 최소의 평균 대기 시간을 제공

비선점형 방식

• 한 번 CPU를 할당 받으면 자신의 CPU Burst Time이 끝나기 전에는 놓지 않는다. 평균 대기 시간 : (0 + 6 + 3 + 7) / 4 = 4 (도착한 시간(Arrival Time)부터 계산함에 유의)

  선점형 방식

• CPU를 할당 받아 수행 중이더라도 CPU Burst Time이 자신의 현재 남은 시간보다 짧은 시간을 가진 프로세스가 새로 생성되면 CPU를 양보한다.
• Shortest Remaining Time First Scheduling (SRTF) 평균 대기 시간 : (9 + 1 + 0 + 2) / 4 = 3

Priority Scheduling

미리 주어진 Priority에 따라 CPU를 할당

• 비선점형 방식 한 번 CPU를 할당 받으면 자신의 CPU Burst Time이 끝나기 전에는 놓지 않는다.
• 선점형 방식 새로 생성된 Process가 현재 실행되는 Process보다 높은 Priority를 가지고 있을 경우, CPU를 양보한다.

문제점 - 기아 상태 (Starvation)

• 낮은 Priority를 가진 Process는 전혀 수행되지 않을 수 있다.

해결 방법 - Aging 기법

• 할당을 기다리는 시간에 따라 Priority를 증가시켜 주는 방법

Round-Robin (RR) Scheduling

CPU를 시간 단위(Time Quantum)로 할당

• 선점형 Scheduling 방식
• 보통 Time Quantum은 10-100ms
• Time Quantum만큼 수행 한 Process는 Ready Queue의 끝으로 들어가 다시 할당을 기다림 전체 CPU Burst Time을 기준으로 각 Process의 응답시간이 짧다.

  Ready Queue 내의 Process

• n개

  Time Quantum

• q시간

  각각의 Process가 할당 받는 시간

• 1/n 만큼의 CPU시간을 q로 쪼개어 할당 받음

  각 Process의 다음 Time Quantum이 돌아오기까지의 대기 시간

• 최대 (n-1)*q

  성능

• q가 클 경우 : FCFS
• q가 작을 경우 : Context Switching에 필요한 시간보다 낮다면 효율이 매우 떨어짐

  Multilevel Queue Scheduling

  Ready Queue를 여러 개의 Queue로 분리하여, 각각에 대해 다른 Sceduling Algorithm을 사용하는 기법

Foreground Queue

• Interactive한 동작이 필요한 Process를 위한 Queue
• Round Robin 기법 사용

Background Queue

• CPU 연산 작업을 주로 수행하는 Process를 위한 Queue
• FCFS 기법 사용

각 Queue에 CPU를 어떻게 할당할 것인지를 결정해야 함

• Queue에 대한 Priority 또는 Time Slice를 사용할 수 있음

Multilevel Feedback Queue Scheduling

Multilevel Queue에서 Process들이 서로 다른 Queue로 이동할 수 있도록 한 Scheduling 기법

• Aging의 한 방법으로 사용됨

필요한 요소들

• Queue의 개수
• 각 Queue마다의 Scheduling 기법
• 언제 Process를 한 단계 높은 Queue로 옮길 것인가
• 언제 Process를 한 단계 낮은 Queue로 옮길 것인가
• 어떤 Process가 특정한 Service를 필요로 할 때 그것을 제공하는 Queue로 옮겨줄 방법 3-Level Feedback Queue Scheduling

즉, 생성되고 8 + 16ms 동안 종료되지 않은 Process는 많은 CPU작업을 필요로 하는 Process로 간주하여 FCFS기법을 이용해 충분한 CPU Time을 할당해주는 Scheduling 방법이다.

Multiple Processor Scheduling

여러 개의 CPU를 사용하는 System의 경우, CPU Scheduling이 더욱 복잡해진다.

AMD의 big.LITTLE

• 각각의 CPU에 서로 다른 I/O 장치가 연결되어 있다면?
• 각각의 CPU가 서로 다르다면? (명령어 set, 처리 속도)

비대칭 멀티프로세싱(Asymmetric Multiprocessing)

• 하나의 CPU만이 시스템 자료 구조 (Scheduling, I/O 작업, 등) 관리
• 모든 CPU가 접근할 경우보다 데이터 공유가 간단히 이루어짐 Kernel Multithread가 지원이 안되는 경우

  대칭 멀티프로세싱(Symmetric Multiprocessing)

• 완전 자유

Multiprocessor Scheduling 방식

Processor Affinity

• 과거에 수행하던 CPU에 Process를 배정하는 방법 (ex. 오늘...3번 Core가 효율 지리던데...)

Load Balancing

• CPU가 동일할 경우, 동일한 Process들을 수행할 수 있음
• CPU마다 각각의 Ready Queue를 둘 경우 일부 CPU에 Process가 집중될 수 있음
• CPU 모두에 하나의 Ready Queue만을 둘 경우 사용 가능한 CPU에 차례대로 Process를 배정

in Linux

• Completely Fair Scheduling (CFS)
• 범용적으로 쓸 수 있는 운영체제로의 역할을 수행하기 위해 CFS 사용

단일 Bus 구조

Bus

• CPU, RAM, I/O 장치 간 데이터가 전송되는 경로
  • Data 버스, Address 버스

단일 Bus

• 하나의 시스템 버스에 여러가지 모듈이 연결
• CPU, Memory, I/O의 속도가 비슷했던 초창기에 발생
• CPU, Memory, I/O의 속도 격차 증가 -> 병목 현상 발생

Bottleneck

• 같은 버스에 연결된 디바이스들 사이의 속도 차이로 인해 발생

• CPU > Memory >>> I/O 순으로 속도의 격차가 발생

• 빠른 디바이스가 처리하는 양 만큼을 느린 디바이스가 처리하지 못함

• 전체 시스템 속도는 느린 디바이스의 속도로 제한 됨

• E.g., CPU는 초당 5단위의 일을 처리할 수 있는데, 메모리가 초당 3단위의 일만을 전달해 줄 수 있다고 할 때, 전제 시스템 속도는 메모리의 속도로 제한된다.

계층적 Bus 구조

세분화된 버스 채용

• CPU Local Bus, Memory Bus, PCI Bus, etc.

이중 버스

• CPU와 I/O 속도 격차로 인한 병목 현상 해결하고자 함
• 빠른 CPU와 메모리는 시스템 버스에 연결
• I/O 장치는 I/O 버스에 연결

I/O Device Basic Concepts

Event Handling Mechanisms

Interrupt

비동기적 이벤트를 처리하기 위한 기법

• E.g., 네트워크 패킷 도착 이벤트, I/O 요청

참고 비동기적이란, 프로그램 내에서 예측 불가함을 의미한다.

Interrupt 처리 순서

• Interrupt Disable
• 현재 실행 상태 (State)를 저장
• ISR(Interrupt Service Routine)로 점프
• 저장한 실행 상태 (State)를 복원
• 인터럽트로 중단된 지점부터 다시 시작

Interrupt에는 우선 순위가 있으며, H/W 장치마다 다르게 설정됨

Note

• ISR은 짧아야 함 (너무 길면 다른 Interrupt 들이 처리되지 못함)
• Time Sharing은 Timer Interrupt의 도움으로 가능하게 된 기술임

Trap

동기적 이벤트를 처리하기 위한 기법

• E.g., Divide by Zero와 같은 프로그램 에러에 의해 발생

• Trap handler에 의해 처리

• Trap Service Routine이 있기 때문에 Interrupt와 유사하지만, Interrupt와 달리 실행 상태(state)를 저장/복원 하지 않음

Intel x86

Interrupt

• Hardware Interrupt

  • Generated externally by the chipset, and it is signaled by latching onto the #INTP pin of the CPU

• Software Interrupt

  • Signaled by software running on a CPU to indicate that it needs the kernel's attention (e.g., System call)

Exception (Trap)

• Occurred when the processor detects an error condition while executing an instruction
• Type of exceptions
  • Fault
  • Trap
  • Abort

XV6 - Interrupt & Exception

• Hardware Interrupt

  • Handled by interrupt vectors defined in vector.S IRQ_TIMER, IRQ_KBD, IRQ_IDE

• Software Interrupt

  • When a user calls a system call, it triggers a software interrupt (T_SYSCALL)

• Both interrupts are handled by using trap mechanism in XV6

I/O 처리 기법

Device Registers

• 보통 하드웨어 장치는 4종류의 Register를 가짐
• Control Register, Status Register, Input Register Output Register
• Register들은 메인 메모리의 일부 영역에 Mapping
  • Mapping된 영역의 주소만 알면, CPU에서 접근 가능

    I/O Controller

• High-Level의 I/O 요청을 Low-level Machine Specific Instruction으로 해석하는 회로
• 장치와 직접 상호작용

Polling

Loop 안에서 특정 이벤트의 도착 여부를 확인하면서 기다리는 방법

Interrupt Handler를 등록하는 방식과 반대되는 개념

Controller나 장치가 매우 빠른 경우, Polling은 Event 처리 기법으로 적당함

이벤트 도착 시간이 길 경우, Polling은 CPU Time을 낭비

• 컴퓨터 시스템에서 CPU Time은 매우 귀중한 자원

  Polling은 흔히 Programmed I/O로 알려진 방식

참고

• CPU가 Polling의 주최, I/O는 Polling 당하는..
• 장치가 매우 빠른 경우 Event 처리 기법으로 적당하지만, 실제로는 대부분 느리기에 Polling은 그렇게 효율적이지는 못함.

Direct Memory Access (DMA)

Polling이 비효율적이라서, DMA를 도입함.

Polling을 사용할 경우, 모든 I/O 연산은 CPU에 의해 진행

전송할 데이터가 클 경우, CPU를 Polling을 위해 I/O Device의 상태 확인 및 버스에 데이터를 쓰는 행위(PIO)에 사용하는 것은 낭비

DMA Controller라는 프로세서 사용

• CPU와 DMA Controller 간의 통신으로 I/O를 수행
• CPU가 DMA Controller에게 I/O를 요청하면, DMA Controller는 CPU를 대신하여 I/O Device와 Main Memory 사이의 데이터 전송을 수행
  • CPU는 I/O 시간 동안 다른 일을 수행할 수 있음

DMA - Read

DMA - Write

DMA vs Polling

DMA - 추가적인 Hardware가 필요하다.

성능 - DMA를 최대한 활용하기 위해서는 적당한 Parallelism이 필요

Ex) Smartphone Camera Pixel을 읽어 들이려고 할 때 DMA가 필요한가?

• YES. Pixel을 CPU가 읽으면 한 세월 걸림...

I/O Device Access 기법

I/O Instruction

Controller는 보통 1개 혹은 그 이상의 Register를 가짐

• Data, Control Signal을 처리하기 위함

  CPU는 Controller의 Register의 Bit Pattern을 읽고 씀으로써 장치와 통신함

• 이러한 기능을 수행하기 위한 명령어들이 제공됨

Memory Mapped I/O

Device Register들을 Memory 공간에 Mapping하여 사용

• Device Register가 Memory 주소에 Mapping이 되면, Register들은 주소 공간의 일부로 여겨짐

CPU는 일반적인 명령어를 사용하여 I/O 작업을 수행

운영체제에서 필요한 H/W 요점

컴퓨터 시스템의 전체적인 구성

• 버스

I/O Event Mechanisms

• Interrupt

• Trap

I/O Handling Mechanisms

• Polling

• DMA

요약 및 정리

CPU가 매우 빨라서 일을 다 시키면... 과부화... 생산적으로, 효율적으로 일을 시키면서 과부화를 줄이려면 어떻게 해야할까.

=> Interrupt / Trap & Polling, DMA를 이용하자.

프로그램이 만들어지는 과정.

Compiler

역할

• 사람이 이해할 수 있는 프로그래밍 언어로 작성된 Source Code를 컴퓨터(CPU)가 이해할 수 있는 기계어로 표현된 Object파일로 변환

Source Code (e.g., C file)

• 프로그램이 수행하고자 하는 작업이 프로그래밍 언어로 표현되어 있다.

Object (e.g., O file)

• 컴퓨터(CPU)가 이해할 수 있는 기계어로 구성된 파일 자체로는 수행이 이루어지지 못함

• 프로세스로 변환*되기 위한 정보가 삽입되어야 함

• Relocatable Addresses(Relative Address)로 표현 심볼들의 주소가 상대적인 값으로 표현됨 (시작주소로부터 26바이트 지점)

Linker

역할

• 관련된 여러 Object파일들과 라이브러리들을 연결하여, 메모리로 로드 될 수 있는 하나의 Executable로 변환

Executable (e.g., exe file)

• 특정한 환경(OS)에서 수행될 수 있는 파일
• 프로세스로의 변환을 위한 Header, 작업 내용인 Text, 필요한 데이터인 Data를 포함한다.
• Absolute Address로 표현 심볼들의 주소가 절대값으로 표현됨

  Compiler와 Linker는 결과물이 수행될 OS와 CPU에 따라 다른 형태의 파일을 만든다.

Loader

역할

• Executable을 실제 메모리에 올려주는 역할을 담당하는 운영체제의 일부

동작 과정

• Executable의 Header를 읽어, Text와 Data의 크기를 결정
• 프로그램을 위한 Address Space를 생성
• 실행 명령어와 Data들을 Executable로부터 생성한 Address Space로 복사
• 프로그램의 Argument들을 Stack으로 복사
• CPU내 Register를 초기화하고, Start-up Routine으로 Jump

Runtime System

역할

• Runtime System은 응용 프로그램의 효율적인 실행을 지원하기 위해, 프로그램과 연결하여 상호 작용함

C Runtime System Program Execution

• GCC는 Start-up Code Object 파일을 추가하여 프로그램을 컴파일 하며, 이 때 기본 라이브러리들도 동적으로 링크 된다.

• Process를 시작하기 위해 커널은 PC(프로그램 카운터)를 _start함수의 주소로 지정한다.

• _start함수는 동적으로 링크된 C 라이브러리 및 쓰레드 환경을 초기화하기 위해 _libc_start_main함수를 호출한다.

• 라이브러리 초기화를 진행한 이후, 프로그램의 main함수가 호출된다.

Process Concept

Process - Abstraction for

• Execution Unit : 스케줄링의 단위
• Protection Domain : 서로 침범하지 못함

Process - Implemented with

• Program Counter
• Stack
• Data Section

프로세스는 디스크에 저장된 프로그램으로부터 변환되어 메모리로 로딩된다.

서로 다른 프로세스들간에는 침범하지 못한다. (Protection Domain)

Transition of Process State

• New : The Process is being created

• Running : Instructions are being executed

• Waiting : The process is waiting for some event to occur

• Ready : The process is waiting to be assigned to a processor

• Terminated : The process has finished execution

커널 내에 Ready Queue, Waiting Queue, Running Queue를 두고 프로세스들을 상태에 따라 관리한다.

Process Control Block

PCB

• 각 프로세스는 PCB에 의해서 OS안에 나타나진다(represented)

Information associated with each process

• Process State
• Program Counter
• CPU Registers
• CPU Scheduling Information
• Memory Management Information
• Accounting Information
• I/O Status Information

Context Switching

• When CPU switches to a new process, kernel must save the state of the old(current) process(기존 프로세스 상태 저장) and load the saved state for the new process(새로운 프로세스 로드).

• Context switching time is overhead System can't do useful work while switching

• Context switching time depends on H/W support

프로세서 구조에 따른 Context Switch의 차이

CISC

• 복잡한 명령어 셋 구성 -> 효율 높임, 클럭 속도 저하
• 복잡한 회로 -> 물리적인 공간 차지 -> 레지스터 용량 저하 e.g., Intel Pentium Processor

RISC

• 간단한 명령어 셋 구성 -> 클럭 속도 높임 -> 빠른 수행 속도

• 절약된 물리적 공간에 보다 많은 레지스터 장착 Context Switch 시 레지스터 내용 변경에 보다 큰 오버헤드가 발생함. e.g., ARM Processor

• Register Window (Berkeley RISC Design) memory에 접근하는 수를 최대한 줄이고자 Register를 이용

참고

Context Switch Diagram

Process Creation

• 프로세스들은 Concurrently하게 실행될 수 있으며, 동적으로 생성/종료 된다.

• OS provides process creation and process termination mechanisms

• Process Creation (i.e., fork())

Process Creation in Memory View

Memory (Text and Data Section)

• Child process is a duplicate of the parent process.

• Child process has a program loaded into it

• Unix example
  • A new process created by fork system call
  • A new process (child process) consists of a copy of the memory of the original process (parent process)
  • Exec(2): to replace the memory with a new program

Process Termination

Process Termination

• A process terminates when it finished executing its final statement and asks the OS to delete it by using exit system call.

  • Output data from child to parent (via wait())

  • Process's resources are deallocated by OS

  • The abort function causes abnormal process termination to occur.

    • The SIGABRT signal is sent to the calling process.
    • Core dump is made.

Cooperating Processes

Independent process cannot affect or be affected by the execution of another process.

Advantages of process cooperation

• Information sharing

• Computation speed-up

• Modularity

• Convenience

운영체제는 규모가 매우 크고 복잡한 소프트웨어

• 설계 시 소프트웨어의 구조를 신중히 고려해야 함

좋은 설계를 통해 쉬워지는 것들

• 개발
• 수정 및 디버깅
• 유지 보수
• 확장

디자인 목표 중에 좋은 것이란?

• 설계하고자 하는 시스템의 목적과 관계가 있음

OS Design Principle

Policy

• What will be done

• Supposed to be higher level, and use mechanism

  Mechanism

• How to do something

• E.g., Concrete Algorithms, Data Structures

Mechanism과 Policy를 분리 함으로써, 운영체제 설계를 보다 Module화 할 수 있음

Methods for Operating System Design

Layering

OS의 복잡도를 낮추기 위한 방안

Layer는 정의가 명확한(Well-Defined)함수들로 이루어짐

하나의 Layer는 인접한 Layer와만 통신

• 위, 아래에 인접한 Layer와만 통신하며, 2단계 이상 건너뛴 Layer와 직접적으로 통신하지 않음

설계의 복잡도를 낮출 수는 있지만, 그로 인해 Overhead가 발생함

• E.g., OSI 7 Layers

  Layering Example

  

Modularity

Layering의 장점

• Layer의 수정이 다른 Layer와 독립적임 모듈성으로 인해 해당 Layer를 갈아 끼우기 좋음

불완전한 Layering

MS-DOS에서는 Layering 원칙을 무시한 Interface 호출로 인한 취약점이 존재했다.

Kernel 내의 모듈들

Linux의 모듈러 구조이다.

Kernel Designs

CPU의 2가지 이상의 실행 모드

• System Protection을 위해서 필요

• 실행 Mode의 권한에 따라, 접근할 수 있는 메모리, 실행 가능한 명령어가 제한됨*

• 각각의 Mode 별로 권한(Privilege)이 설정 됨

• Hardware 지원이 필요

User Mode와 Kernel Mode

Kernel Mode

• 모든 권한을 가진 실행 Mode

• OS가 실행되는 Mode

• Previlege 명령어 실행 및 레지스터 접근 가능

User Mode

• Kernel Mode에 비해 낮은 권한의 실행 Mode

• 어플리케이션이 실행되는 Mode

• Privilege 명령어 실행 불가능

실행 Mode 전환(Execution Mode Switch)

• User Mode에서 실행 중인 Application이 Kernel Mode의 권한이 필요한 서비스를 받기 위한 방법이 필요

System Call

User Mode에서 Kernel Mode로 진입하기 위한 통로

• Kernel에서 제공하는 Protected 서비스를 이용하기 위해 필요 (Open, Write, Msgsnd, Shm) User Program에서 필요에 따라서 System Call을 위해 사용할 매개변수를 레지스터에 저장한다. 이후 System Call에 매핑된 Syscall Num을 이용하여 System call을 호출한다.

Monolithic kernel

특징

• Kernel의 모든 Service가 같은 주소 공간에 위치

• 애플리케이션은 자신의 주소 공간에 커널 코드 영역을 매핑하여 커널 서비스를 이용

• H/W 계층에 관한 단일한 Abstraction을 정의 이를 사용하기 위해, 라이브러리나 애플리케이션에게 단일한(Monolithic) 인터페이스 제공

장점

• 애플리케이션과 모든 Kernel서비스가 같은 주소 공간에 위치하기 때문에, System call및 Kernel 서비스 간의 데이터 전달 시 Overhead가 적음

단점

• 모든 서비스 모듈이 하나의 바이너리로 이루어져 있기 때문에 일부분의 수정이 전체에 영향을 미침
• 각 모듈이 유기적으로 연결되어 있기 때문에 Kernel 크기가 커질 수록 유지/보수가 어려움
• 한 모듈의 버그가 시스템 전체에 영향을 미침

Micro Kernel

특징

• Kernel service를 기능에 따라 모듈화 하여 각각 독립된 주소 공간에서 실행

• 이러한 모듈을 서버라고 하며, 서버들은 독립된 프로세스로 구현

• Micro Kernel은 서버들 간의 통신(IPC) 애플리케이션의 서비스 콜 전달과 같은 단순한 기능만을 제공

장점

• 각 Kernel service가 따로 구현되어 있기 때문에 서로 간의 의존성이 낮음 Monolithic Kernel보다 독립적인 개발이 가능 Kernel의 개발 및 유지 보수가 상대적으로 용이

• Kernel service 서버의 간단한 시작/종료 가능 불필요한 서비스의 서버는 종료 (Resource 확보)

• 이론적으로 Micro Kernel이 Monolithic 보다 안정적

• 서버 코드가 Protected Memory에서 실행되므로, 검증된 S/W 분야에 적합

단점

• Monolithic Kernel보다 낮은 성능을 보임 독립된 서버들 간의 통신 및 Context Switching

Hypervisor

특징

• 가상화된 컴퓨터 H/W 자원을 제공하기 위한 관리 계층 Guest OS와 H/W 사이에 위치함 Guest OS-Hypervisor가 제공하는 가상화된 H/W 자원을 이용하는 운영체제

• 각 Guest OS들은 각각 서로 다른 가상 머신(VMs)에서 수행되며, 서로의 존재를 알지 못함 H/W에 대한 접근은 Hypervisor에게 할당 받은 자원에 대해서만 수행

• Hypervisor는 각 Guest OS간의 CPU, 메모리, 등 시스템 자원을 분배하는 등 최소한의 역할을 수행

  장점

• 하나의 물리 컴퓨터에서 여러 종류의 Guest OS의 운용이 가능 한 서버에서 다양한 서비스를 동시에 제공

• 실제의 컴퓨터가 제공하는 것과 다른 형태의 명령어 집합 구조(Instruction Set Architecture)를 제공

단점

• H/W를 직접적으로 사용하는 다른 OS에 비해 성능이 떨어짐 반가상화(Para-Virtualization)로 성능저하 문제를 해결하려 함

Mono VS. Micro VS. Hypervisor

• Compute + er

• 2차 세계대전 암호 해석 미사일 탄도 분석 물리 계산

  Hand-operated System

  1950년대 초반

• 당시 컴퓨터는 현재의 컴퓨터에 비해 매우 원시적임

• 프로그램인 기계적인 스위치를 이용하여, 1bit 단위로 컴퓨터에 입력되어 실행 진공관 기반-> 집채만 한 크기, 많은 열 방출

1950년대 중반

• 모든 프로그램은 기계어로 쓰여짐

• 플러그 보드(Plug-Board)에 와이어링(Wiring)을 통해 컴퓨터의 기능을 제어

• 프로그래밍 언어 및 운영체제라는 존재가 없음 영구적인 저장장치가 없음 - 매번 프로그램 다시 입력

1960년대 초반

• 펀치카드가 등장

• 프로그래밍한 카드로 컴퓨터 구동 플러그보드 대체

Batch System

• Mainframe - 일괄처리(Batch) : 펀치카드를 기반으로 한 대표적인 컴퓨터 시스템 => 이 시기부터 OS의 시작이라고 봐도 됨

  상용 시스템(Business Machinery)로써 쓰이면서 가치가 발생

• 계산을 하는데 주로 사용되기 시작함

• 교량(Bridge) 설계 등.

일괄 처리 - 아주 단순한 OS 개념

• 일단 시작한 "Job"은 끝나야 다음 Job이 수행됨

• Punch card를 제출하면, 메모리에 적재, 수행의 순서로 진행

• 결과를 받기까지 중간에 User Interaction이 불가능함

• 사람이 Job Scheduling 함 => 현대 OS에서 가장 중요하다 여기는...(Scheduling)

CPU는 빈번히 Idle 상태로 전환됨

• 기계적인 I/O 장치와 전기 장치인 CPU사이에 현격한 속도 차이 존재

Automatic Job Sequencing

• 사람의 관여 없이, 여러 개의 프로그램을 순차적으로 실행
• 이전 작업이 종료되자마자 다음 작업을 실행하기에, 일괄 처리(Batch)보다 성능이 향상됨
• 일괄 처리* : 사람이 직접 스케줄링
• Automatic Job Sequencing* : 스케줄링을 담당하는 소프트웨어가 프로그램 실행
• I/O에 의해 CPU가 Idle 상태로 전환되는 문제는 해결 X 현대 OS에서도 해결 못함... But, 멀티프로세싱을 이용함

프린터로 요청을 보내면 프린터가 작업을 완료할 때 까지 Blocked

Spooling Batch System

Spooling - 초기 해결책

CPU Idle 해결을 위한 해결책

• Simultaneous Peripheral Operation On-Line

• I/O와 Computation을 동시에 진행할 수 있음 ex) 프린터 Spooling

  • 인쇄할 문서를 디스크나 메모리의 버퍼에 로드
  • 프린터는 버퍼에서 자신의 처리 속도로 인쇄할 데이터를 가져옴
  • 프린터가 인쇄하는 동안 컴퓨터는 다른 작업을 수행할 수 있음

• Spooling을 통해 사용자는 여러 개의 인쇄 작업을 프린터에 순차적으로 요청할 수 있음 이전 작업의 종료를 기다리지 않고, 버퍼에 인쇄 작업을 로드하여 자신의 인쇄 작업을 요청함

Multiprogramming

2개 이상의 작업을 동시에 실행

• 운영체제는 여러 개의 작업을 메모리에 동시에 유지
• 현재 실행중인 작업이 I/O를 할 경우, 다음 작업을 순차적으로 실행
• 스케줄링 고려사항 - First Come First Served 왼쪽이 Batch 시스템 (Job1이 끝나야, Job2가 실행됨) 오른쪽이 Multiprogramming 시스템

Multiprogramming의 목적

• CPU 활용도(Utilization)증가 == CPU Idle Time 감소 CPU는 빠르고 비싸니깐, 최대한 놀게 하지 말자(최대한 활용하자)

  단점

• 사용자는 여전히 실행중인 작업에 대해서는 관여할 수 없음

Issues with Multiprogramming

• 다른 작업으로 넘어가려면 중간에 I/O를 해야만 함.(Voluntary Yield에 의존) => 의도적으로 I/O를 안 함

• 공평성을 유지할 필요 발생 누구나 컴퓨터를 오래 많이 쓰고 싶어한다. (S/W 개발자 입장에서는 의도적으로 I/O를 피해서 계속 CPU를 점유하고 싶음)

• High Priority로 수행할 필요도 생김

• Job Scheduling으로는 해결 안됨

  Timesharing

  CPU의 실행 시간을 타임 슬라이스(Time Slice)로 나누어 실행

• E.g., 10ms

모든 프로그램은 타임 슬라이스 동안 CPU를 점유하고, 그 시간이 끝나면 CPU를 양보

여러 개의 작업들이 CPU 스위칭을 통해 동시에 실행됨

CPU 스위칭이 매우 빈번하게 일어남

• 사용자는 실행중인 프로그램에 관여가 가능

Multitasking

여러 개의 Task들이 CPU와 같은 자원을 공유하도록 하는 방법

하나의 작업(Job)은 동시에 실행할 수 있는 Task로 나눠질 수 있음

• ex) Unix의 프로세스는 fork() 시스템 콜을 이용해서 여러 개의 자식 프로세스를 생성할 수 있음
• ex) 안드로이드 애플리케이션은 UI처리 프로세스, 입출력 처리 프로세스, 계산 처리 프로세스 등 다수의 프로세스를 생성할 수 있음

Multitasking은 사용자가 여러 개의 프로그램을 실행할 수 있도록 하며, CPU가 Idle 상태일 때는 Background 작업을 실행 가능하도록 함

Example of DBMS Multitasking

Fork를 이용한 Child Process 생성

• 멀티태스킹 : 여러 프로그램이 동시에 수행 (Concurrent Execution)
• 하나의 태스크가 다른 태스크(Child Process)를 만들 수 있는 기능을 의미함
• 자신이 필요한 기능을 Child Process 형태로 만들어 서로 협력을 통한 작업 수행

Issues with Multitasking System

복잡한 메모리 관리 시스템

• 동시에 여러 개의 프로그램이 메모리에 상주
• 메모리 관리 및 보호 시스템 필요

적절한 응답 시간을 제공

• Job들은 메모리와 디스크로 Swap In/Out될 수 있음

Concurrent Execution 제공

• CUP 스케줄링 필요

필요에 따라서 Job들 간의 Orderly Execution이 필요

• 동기화, Deadlock

Lineage of Well-known Operating Systems

그 외 시스템

Multiprocessor Systems

• Symmetric VS. Asymmetric Multiprocessors (Asymmetric => ARM big.Little CPU Architecture)

분산시스템

• LAN/WAN으로 연결
• Client-Server Model, Peer-to-Peer Model
• Bus와의 차이는?

Clustered Systems

• 공동의 목적을 위해 여러 개의 시스템 네트워크를 통해 작업을 수행

Embedded Systems

• 특정 목적을 위한 운영체제 및 소프트웨어가 탑재된 형태의 시스템
• MP3 Player, Smartphone, etc.

Real-Time Systems

• 시스템에서 수행하는 작업의 완료시간(Deadline)이 정해짐
• Soft Real-Time, Hard Real-Time

정리 및 요약

• 컴퓨터는 본래 계산을 위해 개발되었다. 프로그래밍 언어 및 OS라는 개념이 없었던 시절(1950~)에는 매번 프로그램을 재작성하여 사용했었음. 이후, 펀치카드가 발명되고** Batch 시스템**이 상용화 되었지만 그럼에도 불구하고

1. 사람이 Job Scheduling을 진행함 2. 이전의 Job이 끝나야지만 다른 Job을 수행할 수 있다는 문제(CPU가 빈번히 Idle됨)가 있다.

1번을 해결하기 위해 사람의 관여 없이, 여러 개의 프로그램을 순차적으로 실행하는 Automatic Job Sequencing을 도입하여 Batch 시스템보다 성능이 향상되었다.

하지만, 여전히 CPU의 Idle문제를 해결하지 못했는데 CPU의 Utilization을 높이기 위해서 Spooling을 도입하였다.

Multiprogramming이란, 2개 이상의 작업을 동시에 실행하는 것을 의미한다. OS는 여러 개의 작업을 메모리에 동시에 유지하고, 현재 실행중인 작업이 I/O를 할 경우에 다음 작업을 순차적으로 실행한다. 이 역시, CPU Utilization을 높이기 위해서 사용했지만, 여전히 사용자는 실행중인 작업에 대해서는 관여할 수 없었다.

• High Priority로 수행할 필요도 생김
• 다른 Job이 수행되려면 I/O가 필요함.

=> Time sharing 도입.

Multitasking이란, 여러 개의 Task들이 CPU와 같은 자원을 공유하도록 하는 방법. 하나의 Job은 동시에 실행할 수 있는 Task로 나눠질 수 있다. Multitasking은 사용자가 여러 개의 프로그램을 실행할 수 있도록 하며, CPU가 Idle 상태일 경우에 Background 작업을 실행 가능하도록 한다.

What happens when a program runs?

• A running program executes instructions.

1. 프로세서는 메모리로부터 명령어를 fetch한다.
2. 어떤 명령어인지 Decode한다.
3. 명령어에 적혀있는 Opcode 및 Operands를 기반으로 Execute한다.
4. 프로세서는 다음 명령어(PC + 4)로 이동하여 동일한 수행을 반복한다.

Von-neunmann의 CPU Architecture (Fetch & Execution Cycle)

Operating System is

Responsible for

• 프로그램을 실행하기 쉽게 (run)
• 프로그램들이 메모리를 잘 활용하도록 (Share)
• 디바이스와 통신할 수 있도록 (Interact)

OS는 시스템이 올바르고 효율적으로 동작하도록 한다.

What is OS?

• 하드웨어를 손쉽게 그리고 효율적으로 사용할 수 있는 Abstraction을 제공한다.

1. CPU : Process
2. Memory : Address Space
3. Disk : File
4. Network : Port

• 자원의 공유 및 분배를 위한 Policy를 결정한다. Policy : FIFO, LRU 등...

  설계 결정 (Design Decisions)이 중요 (데이터 센터, 스마트폰에 사용되는 Policy가 다르다.)

Abstraction : Process

Program

• 컴퓨터를 실행 시키기 위한 일련의 순차적으로 작성된 명령어의 모음
• 컴퓨터 시스템의 Disk와 같은 Secondary Storage에 바이너리 형태로 저장되어 있다.

Process

• 실행되고 있는 프로그램의 추상화 (Abstraction)
• PC, Stack, Data Section으로 구현된다.

  왜 필요할까?

  CPU와 같은 H/W Component로 하여금, 각 Program을 구분하여 인식/실행할 수 있도록 하기 위함

Abstraction : Address Space

Address Space

• Process가 차지하는 메모리 공간

  왜 필요할까?

• Protection Domain : 서로의 공간을 침범할 수 없음 (멀티 프로세스는 예외지만...)
• I/O Device의 관리를 위해서

Abstraction : File

File

• Process에서 읽고 쓸 수 있는 Persistent Storage(비휘발성의, 영구적인)
• 실제 저장되는 위치를 Process는 알지 않음

왜 필요할까?

어디까지가 Process의 Binary Data인지, 해당 Binary Data가 어디에 저장되어 있는지 관리/유지 필요

Abstrcation : Port

Port

• 컴퓨터 시스템이 메시지를 주고 받는 Communication Endpoint

  왜 필요할까?

  어떤 Process(또는 User)가 통신의 대상인지 구분 필요
• Privacy Issue 포함 (특정 프로세스만 패킷을 볼 수 있다)

Policy

왜 필요할까?

현재 운영체제가 사용되는 영역은 다양하지만, 해당 영역에 따라서 요구되는 것들이 다르다. (ex. 성능, 배터리 소모, 안전 등등)

Software 구분

• System Software : 컴퓨터 시스템을 구동시키는 SW (Low-level) Compiler/Assembler

• Application Software (High-level) : 특정 용도로 사용됨 word, Internet Explorer, etc.

운영체제의 특징 (Application과 비교)

OS는 항상 동작

통제 기능으로서, 항상 자원에 대한 관리/감시 활동

• Supervisor Mode == Kernel Mode (<-> User Mode) eg. 어떤 Process가 어떤 자원을 사용하고 있는지 어떤 Process에 어떤 자원을 할당해 줄 것인지

하드웨어에 대한 제어 기능

• Device Driver eg. 그래픽 카드를 메인보드에 꽂았을 때, Driver를 설치하여 OS가 H/W를 제어한다. (해당 H/W를 효율적으로 사용)

OS / Kernel

OS와 Kernel에 대한 두 가지 관점

1. OS = Kernel
2. OS = Kernel + GUI + Library

Kernel

• 운영체제의 핵심 부분으로, 자원 할당, 하드웨어 인터페이스, 보안 등을 담당

  GUI

• 그래픽 사용자 인터페이스 eg. iOS vs Android

  Library

• 자주 사용되는 함수들의 집합 eg. libc, win32.dll

 Automatic Dependent Surveillance-Broadcast(ADS-B) has been widely adopted as the de facto standard for air-traffic surveillance. Aviation regulations require all aircraft to actively broadcast status reports containing identity, position, and movement information. However, the lack of security measures exposes ADS-B to cyberattacks by technically capable adversaries with the purpose of interfering with air safety. In this paper, we develop a non-invasive trust evaluation system to detect attacks on ADS-B-based air-traffic surveillance using real-world flight data as collected by an infrastructure of ground-based sensors. Taking advantage of the redundancy of geographically distributed sensors in a crowdsourcing manner, we implement verification tests to pursue security by wireless witnessing. At the core of our proposal is the combination of verification checks and Machine Learning (ML)-aided classification of reception patterns--such that user-collected data cross-validates the data provided by other users. Our system is non-invasive in the sense that in neither requires modifications on the deployed hardware nor the software protocols and only utilized already available data. We demonstrate that our system can successfully detect GPS spoofing, ADS-B spoofing, and even Sybil attacks for airspaces observed by at least three benign sensors. We are further able to distinguish the type of attack, identify affected sensors, and tune our system to dynamically adapt to changing air-traffic conditons.

 방송형 자동종속관제(ADS-B)는 항공 교통에 대한 표준으로 널리 채택되었다. 항공 규제들은 신원, 위치, 이동 정보 등을 포함하는 상태 보고서를 적극적으로 방송하도록 요구한다. 하지만, 보안 조치의 부족함은 ADS-B를 항공 안전을 방해 할 목적으로 기술적 능력을 가지는 적에 의한 사이버 공격에 노출시킨다. 이 논문에서는, 우리는 지상-기반 센서 인프라에 의해 수집된 실제 항공 데이터를 가지고 ADS-B기반의 항공 교통 관제에 대한 공격을 탐지하기 위한 비침입적 신뢰 평가 시스템을 개발한다. 크라우드소싱 방식으로 지리적으로 분산된 센서들의 중복성의 이점으로, 우리는 무선 목격을 통한 보안을 추구하기 위한 검증 테스트를 개발한다. 우리 제안의 중점은 사용자가 수집한 데이터가 다른 사용자에 의해 제공된 데이터를 상호 검증하도록, 검증 테스트와 기계 학습 기반의 수신 패턴 분류를 조합하는 것이다. 우리의 시스템은 이미 배포된 하드웨어나 프로토콜들에 대한 수정 없이 오직 이미 사용가능한 데이터만을 활용한다는 점에 있어서 비침입적이다. 우리는 우리의 시스템이 성공적으로 GPS spoofing, ADS-B spoofing, 그리고 심지어 최소 3개의 정상 센서들에 의해 목격되어진 영공에 대한 Sybil attacks를 탐지할 수 있다는 것을 증명했다. 우리는 심지어 공격의 유형을 구분하고, 영향을 받은 센서들을 식별하고, 변화하는 항공 교통 제어를 위해서 동적으로 우리의 시스템을 조정할 수 있다.

Abstract 정리

ADS-B는 항공교통관제에 있어서 표준이 되었다. 하지만 ADS-B에 대한 보안 조치가 부족하여 사이버 위협에 취약한 상황이다. 이러한 상황에서 우리는 지리적으로 분산되어있는 사용자들로 부터 수집되는 데이터를 활용하여 공격 탐지 평가 시스템을 개발한다. 우리의 시스템은 이미 배포된 하드웨어나 프로토콜에 대한 수정이 필요없는 비침입적 시스템이며, 다양한 공격들(GPS spoofing, ADS-B spoofing, Sybil attacks 등)의 유형을 식별하고 공격 당한 센서를 식별하는 등의 특징을 가지고 있다.

Introduction

 The monitoring of air traffic has evolved from an analog Radio Detection and Ranging (RADAR)-based system to a digitally-aided surveillance infrastructure. Effective from January 1, 2020, all aircraft are required to be equipped with an Automatic Dependent Surveillance-Broadcast (ADS-B) system to access most of the world's airspace, which hence constitutes the de facto standard for air-traffic monitoring. ADS-B-capable transmitters periodically broadcast status reports that inform others about their identification, position, movement, and additional status codes.

 항공 교통 모니터링이 아날로그 RADAR 기반의 시스템에서 디지털을 지원하는 감시 인프라 체계로 발전해왔다. 2020년 1월 1일 부터, 모든 항공기들은 거의 대부분의 전 세계 영공을 접근하기 위해서는 ADS-B 시스템을 장비하도록 요구되어졌고, 이는 곧 사실상의 표준이 되었다. ADS-B를 이용할 수 있는 송신자들은 다른 항공기들에게 그들의 신원, 위치, 이동, 그리고 추가적인 상태코드들을 알리는 상태 보고서를 주기적으로 방송한다.

 While the aviation industry is characterized by very long development cycles--up to several decades--, applications that mandate high safety guarantees are usually lagging behind advacements on the security side. As such, ADS-B reports are neither encrypted nor authenicated. At the same time, the open specification of ADS-B promotes the collection and free usage of aircraft reports. Simple sensors can decode aircraft broadcast reports and gain a real-time view of their surrounding airspace. A network that combines more than 1000 user-operated ground-based sensors in a crowdsourcing manner is the OpenSky Network. This network collects and stores air-traffic data from around the world and makes them available for research.

 항공 산업이 아주 긴 개발 주기가 특성인 반면에, 고수준의 안전을 보장 해야하는 애플리케이션들은 보통 보안 측면의 발전 보다 뒤떨어져있다. ADS-B 보고서들은 암호화나 인증되어지지 않는다. 동시에, ADS-B의 공개 명세서는 항공기 보고서들의 수집과 무료 사용을 촉진시켰다. 단순한 센서들은 항공 방송 보고서들을 해독할 수 있고 그들을 둘러싸고 있는 영공의 실시간 뷰를 얻을 수 있다. OpenSky Network는 1000개 이상의 크라우드 소싱 방식의 유저에 의해 수행되는 지상 기반의 센서들로 구성되어지는 네트워크이다. 이 네트워크는 전 세계로부터 항공 교통 데이터를 수집하고 저장한다 그리고 그것들을 연구를 위해 사용 가능하게 만든다.

 Since ADS-B lacks fundamental security practices, the exposrue to cyberattacks targeting air traffic has long been discussed. These works demonstrate how attackers can interfere with aircraft sensors and how fake aircraft messages can be injected into air-traffic monitoring systems. For instance, adversaries with commercial off-the-shelf hardware and moderate knowledge can generate arbitrary messages mimicking valid ADS-B reports. The consequences of such attacks range from distraction on the flight deck or in the control room up to violations of mandatory safety separations, and eventually increasing the possibilty of aircraft collisions. Since the implementation of theses attacks is far from being only of academic nature, security solutions are urgently needed to protect the integrity of air-traffic surveillance. In fact, data trust establishment is an open and central problem in the aviation industry and emerging concerns have already reached the public.

 ADS-B가 근본적인 보안 정책이 부족하기 때문에, 항공 교통을 타겟으로하는 사이버공격에 대한 노출은 오랫동안 논의되어왔다. 이러한 작업들은 어떻게 공격자들이 항공기 센서들을 방해할 수 있고 가짜 항공기 메시지들이 어떻게 항공 교통 관제 시스템에 주입될 수 있는지를 증명한다. 예를 들어서, 기성품 하드웨어와 보통의 지식을 가진 적들은 유효한 ADS-B 보고서들을 모방하는 임의의 메시지를 생성할 수 있다. 이러한 공격들의 결과는 비행 갑판 또는 제어실에서의 주의산만에서 의무적인 안전 분리 위반까지에 이르기까지 다양하며, 결국 항공기 충돌의 가능성까지 증가시킨다. 이러한 공격들의 구현이 학문적 성격에 불과하지 않기 때문에, 항공 교통 관제 감시의 무결성을 보호하기 위해 보안 솔루션들이 시급해진다. 사실, 데이터 신뢰 구축은 항공 산업의 개방적이고 중심적인 문제이며, 새로운 우려들은 이미 대중들에게 도달했다.

참고 off-the-shelf 라는 단어는 보안 외신에서 자주 사용되는 일종의 형용사처럼 쓰이는 단어이다. '판매대에서 떨어져 나온'이라는 직역처럼 구매했다 라는 뜻으로 사용된다. 즉, off-the-shelf라는 단어는 다음과 같은 뜻을 내포하고 있는 것이 보통이다.

• 공격자들이 스스로 그것을 개발할 정도의 기술을 가지고 있지 않다.

• 누구나 사용할 수 있는 기성품이 공격에 활용된다. 위 본문에서는 off-the-shelf라는 단어를 사용함으로써 전문 지식이 없는 공격자들이 기성품 하드웨어의 구매와 약간의 지식으로도 쉽게 ADS-B에 대한 공격을 수행하고 있다라고 생각하면 된다.

  To answer the demands for more security in the safety-driven aviation industry, we propose a data-centric trust evaluation system with the goal of assessing the trustworthiness of ADS-B reports using data that is already collected at wide scale. We refer to trust in the sense that messages are trustworthy when they originate from functional, non-malicious sources. In contrast, error-prone or attacker-controlled messages trying to harm the system should be detected. Furthermore, we explore the identification of the type of attack and the traceability of malicious sensors.

 안전한 항공 산업의 더 나은 보안에 대한 요구에 대답하기 위해서, 우리는 이미 광범위하게 수집된 데이터를 활용하는 ADS-B 보고서들의 신뢰성을 평가하는 것을 목표로 가지는 데이터 중심의 신뢰 평가 시스템을 제안한다. 우리는 메시지들이 기능적이고, 비위협적인 소스로부터 기원되었을 때, 신뢰적이다라는 의미에서의 신뢰를 말하고 있다. 이와 대조적으로, 시스템에 해를 끼지려고하는 에러가 쉽게 발생하거나 공격자-통제적인 메시지들은 탐지되어야 한다. 게다가, 우리는 공격의 유형 식별과 악의적인 센서들의 추적을 살펴봐야한다.

The development of such a system faces several challenges imposed by the highly regulated aviation industry. Viable solutions need to be non-invasive in the sense that they do not require any modifications on the deployed hard-and software. In particular, security systems should not interfere with other systems already in place to avoid lengthy (re)certification processes. Preferably, solutions are augmentation systems that operate autonomously with sensor input already available. We develop our system to fulfill all these challenges.

 이러한 시스템의 발전은 매우 규제되어있는 항공 산업에 의한 여러가지 문제들을 직면한다. 생존가능한 솔루션들은 이미 배포된 하드웨어나 소프트웨어에 대한 어떠한 수정도 요구하지 않는 의미의 비침입성이 필요하다. 특히, 보안 시스템들은 긴 절차의 (재)인증 프로세스들을 피하기 위해서 이미 자리를 잡은 다른 시스템들과 방해하면 안된다. 가급적으로, 솔루션들은 이미 사용가능한 센서 인풋을 가지고 자동적으로 수행하는 증강 시스템들이다. 우리는 이러한 모든 문제들을 충족하기 위해서 우리의 시스템을 개발한다.

At the core of our system, we make use of the crowd-sourcing nature of a sensor network in which user-collected data cross-validates data provided by other users. Forming a network of trusted sensors based on mutual auditing, we pursue wireless witnessing. Wireless witnessing is the collaborative process of observing the status of a distributed wireless system. We apply it in the security context to assess and validate the trustworthiness of ADS-B reports. In particular, we implement a Machine Learning (ML)-based verification test that is trained on typical message reception patterns. The collaboration of sensors characterizes expected reception patterns of aircraft reports transmitted from certain airspace segments while automatically factoring in natural message loss.

 우리 시스템의 중심에 있어서, 우리는 유저-수집 데이터들이 다른 유저들에 의해 제공된 데이터를 교차 검증하는 센서 네트워크의 크라우드 소싱 방식의 특성을 활용하는 것이다. 상호 감사를 기반으로하는 신뢰된 센서들의 네트워크를 형성하는 것은, 우리가 무선 목격을 추구하는 것이다. 무선 목격은 분산 무선 시스템의 상태를 관찰하는 협업 절차이다. 우리는 그것을 ADS-B 보고서들의 신뢰성을 평가하고 검증하기 위해서 보안 분야에 적용시켰다. 특히, 우리는 특정 메시지 수신 패턴을 학습한 기계 학습 기반의 검증 테스트를 구현했다. 센서들의 협업은 자연스러운 메시지 손실을 자동적으로 고려하면서 특정 영공 세그먼트로부터 전송되어진 항공기 보고서들의 기대되어지는 수신 패턴들을 특징화 한다.

Our system can reliably differentiate between normal air-traffic broadcast and suspicious reports diverging from expected patterns if at least three sensors observe the same airspace. This assumption is already fulfilled by the majority of the considered airspace. Furthermore, our system can recognize the type of attack, e.g. GPS spoofing or ADS-B spoofing to trace affected sensors and identify the sensor redundancy as an important factor. While minimizing false alarm events, we achieve detection rates beyond 95% for moderate GPS spoofing deviations and any form of ADS-B spoofing. To further harden the network against attacks, new sensors can be integrated by providing consistent snapshots of their airspaces. Since our system is solely based on an already existing infrastructure and does not require any modifications on aviation systems, it is non-invasive and could be implemented today easing very long certification processes. In contrast to existing solutions for air-traffic verification, we do not require the measurement of time, frequency shifts, or any PHY layer features, but only use discrete sensor events.

 우리의 시스템은 최소 3개의 센서들이 같은 영공을 관찰 할 경우, 정상 항공 교통 방송과 예상 패턴들과는 다른 의심이 가는 보고서들을 분리할 수 있다. 이러한 가정은 이미 고려되는 영공의 대부분에 의해서 충족된다. 게다가, 우리의 시스템은 GPS spoofing이나 ADS-B spoofing같은 공격의 유형을 구분함으로써 영향을 받은 센서들을 추적하고 센서 이중화를 중요한 요소로 식별할 수 있다. 잘못된 이벤트를 알리는 것을 최소화하는 반면에, 우리는 중간정도의 GPS spoofing 편차와 ADS-B spoofing의 어떠한 형태라도 95%이상의 탐지율을 달성한다. 공격에 대한 네트워크를 더 견고히 하기 위해서, 새로운 센서들이 그들의 영공의 일관된 스냅샷을 제공함으로써 통합되어질 수 있다. 우리의 시스템이 이미 존재하는 인프라를 기반으로 하고 있고 항공 시스템의 어떠한 수정도 요구하고 있지 않기 때문에, 비침입적이고, 매우 긴 인증 절차들을 용이하게 하면서 구현될 수 있다. 기존의 항공 교통 검증에 대한 솔루션들과는 대조적으로, 우리는 시간, 주파수 이동, 또는 모든 PHY 계층 기능들의 측정을 요구하지 않고, 오직 이산 센서 이벤트들을 사용한다.

In summary, the contributions of this paper are:

• We propose the first comprehensive approach to evaluate the trustworthiness of ADS-B aircraft reports based on an existing infrastructure of crowdsourcing sensors.
• We demonstrate the applicability of our approach by incorporating real-world flight data collected by geographically distributed sensors at a large scale.
• We simulate prominent attacks on GPS and ADS-B, detect their presence via validation in our trust system, and draw conclusions about their type and origin.
• We elaborate on network expansion and optimized sensor deployment to further harden the network against attacks in the future.

 요약해서, 이 논문의 공헌은 다음과 같다.

• 우리는 기존의 크라우드소싱 센서들의 인프라를 기반으로 ADS-B 보고서들의 신뢰성을 평가하는 최초의 종합적인 방법을 제안한다.
• 우리는 지리적으로 분산된 센서들에 의해 수집된 실제 항공 데이터를 대규모로 통합하여 우리의 방식의 적용 가능성을 증명한다.
• 우리는 GPS와 ADS-B에 대한 두드러지는 공격들을 시뮬레이션하고, 우리의 신뢰 시스템의 검증을 통해서 그들의 존재를 탐지하고, 그리고 그들의 유형과 기원에 대한 결론들을 도출했다.
• 우리는 네트워크 확장과 최적화된 센서 배포에 자세히 설명하여 향후 발생할 공격에 대하여 네트워크를 더욱 견고하게 한다.

Introduction 정리

이 논문에서는 크라우드소싱 방식으로 무선 목격을 추구할 뿐 아니라, 비침입적이라는 성격을 가지는 신뢰 평가 모델을 소개하고 있다. 제공하고 있는 시스템은 공격 유형을(GPS spoofing, ADS-B spoofing) 식별할 수 있고 효과적으로 공격을 탐지할 수 있다. 또한 비침입적이라는 성격을 통해서 기존의 시스템에 적용 가능성과 추후 공격에 대한 네트워크 구축에 대해서 설명할 것이다.

System and Attacker Models

 We first describe today's air-traffic monitoring techniques with a focus on ADS-B. We then introduce our trust definition and present the consolidated system model. Finally, we define the considered attacker model.

 우리는 먼저 ADS-B에 초점을 맞추어 오늘날의 항공 교통 관제 기술에 대해서 설명한다. 이후에 우리의 신뢰 정의를 소개하고 통합 시스템 모델을 도입한다. 마지막으로, 우리는 고려되는 공격 모델을 정의한다.

1. Air-Traffic Monitoring

 In recent years, traditional analog RADAR-based systems for air-traffic monitoring have been augmented with digital means for active wireless communication. For the communication with ground stations and other aerial vehicles, aircraft are mandated to be equipped with ADS-B transponders that periodically broadcast status reports. These reports contain aircraft identification, information on speed, track, and acceleration along with further observation data. The positioning information is mainly derived via GPS, which is the preferred method for self-localization.

 최근 몇 년 동안에, 항공 교통 모니터링을 위한 전통적인 아날로그 RADAR기반의 시스템들은 능동적인 무선 통신을 위한 디지털 수단으로 보강되어졌다. 지상국과 다른 비행체들과의 통신을 위해서, 비행체들은 주기적으로 상태 보고서를 방송하는 ADS-B 수신기를 장착해야 한다. 이러한 보고서들은 비행기 신원, 스피드 정보, 경로, 가속도와 추가 관찰 데이터 등을 포함한다. 위치 정보는 주로 자체 위치 파악에 선호되는 방식인 GPS를 통해 도출된다.

 Since the ADS-B protocol is openly specified, the modulation and data frame patterns are known. ADS-B operates at a frequency of 1,090 MHz and the typical reception range can reach up to 700km. The signals can thus be received by simple consumer-grade hardware such as Universal Software Radio Peripherals (USRPs) or even cheaper Software Defined Radios (SDRs) like RTL-SDR dongles, which are available for as low as $20. The availability of SDRs not only allows passive eavesdropping but also led to software tools for active ADS-B transmission or the generation of fake GPS signals. Surprisingly, the ADS-B protocol lacks fundamental security measures, and neither applies encryption nor authentication.

 ADS-B 프로토콜이 공개적이기 때문에, 변조 및 데이터 프레임 패턴들은 알려져있다. ADS-B는 1,090 MHz 주파수 대역에서 수행되고 전형적인 수신 범위는 700km까지 도달할 수 있다. 신호들은 USRP나 20$도 하지 않는 RTL-SDR동글과 같은 훨씬 저렴한 SDR과 같은 단순한 소비자 등급 하드웨어에 의해 수신될 수 있다. SDRs의 사용가능성은 수동적 도청뿐 아니라 활성 ADS-B 전송이나 가짜 GPS 신호들의 생성을 위한 소프트웨어 툴이 될 수 있다. 놀랍게도, ADS-B 프로토콜은 근본적인 보안 측정이 부족하다, 그리고 암호화와 인증이 적용되어 있지 않다.

2. Trsut Definition

 We define trust in our system as the certainty of an ADS-B report to be the result of normal behavior and not disrupted by malfunctioning or active manipulation. To this end, a trusted report represents valid data transmitted by genuine sources. On the other hand, an untrustworthy report is either erroneous or contains fake data that should be discarded from further processing. While the traditional notion of trust had been entity-centric and rigid, today's fast-changing ad hoc networks necessitate the adjustment of trust models.

 우리는 신뢰를 정상 동작의 결과와 오작동이나 능동적인 조작에 의해서 중단되지 않는 ADS-B 보고서의 확실성으로써 정의한다. 끝에서는, 신뢰된 보고서는 진짜 소스들에 의해 전송되어진 유효한 데이터를 의미한다. 반면에, 비신뢰적 보고서는 에러가 존재하거나 이후 절차에서 제거되어져야만 하는 가짜 데이터를 포함하고 있는것을 의미한다. 신뢰의 전통적인 언급이 개체-중심이고 엄격했던 반면에, 오늘날의 빠르게 변화하는 ad-hoc 네트워크들은 신뢰 모델들의 조정을 필수로 한다.

 Hence, we seek to establish a data-centric trust model in consideration of short-lived associations in volatile environments as mentioned by Raya et al. In particular, we design a trust system that is driven by data collected by geographically distributed sensors that share their observations within a network. The combination of redundant views enables the systems to cross-validate data and eventually establish a form of wireless witnessing.

 따라서, Raya 등이 언급한 바와 같이 변동성이 큰 환경에서의 단명 연관성을 고려하여 데이터 중심 신뢰 모델을 구축하고자 한다. 특히, 우리는 네트워크 안에서 그들의 관측을 공유하는 지리적으로 분산된 센서들에 의해 수집된 데이터로 도출되는 신뢰 모델을 설계했다. 많은 관점의 조합은 시스템들이 데이터를 교차검증 할 수 있도록 하고 결국에는 무선 목격의 형태를 구축한다.

3. Consolidated System Model

 We consider the following system model. Aircraft that are equipped with an ADS-B transmitter periodically broadcast status reports which among other information include GPS-derived positions. A set of geographically distributed sensors receive these reports and their observations are shared with others in a crowdsourcing manner. A central server collects and processes the forwarded observations. Overall, we are faced with the high mobility of aircraft, while the receiving sensors are stationary and are less likely to move significantly. Figure 1 depicts an overview of our system model that we consider to assess the trustworthiness of ADS-B reports.

 우리는 다음과 같은 시스템 모델을 고려한다. ADS-B 송신기를 장착한 항공기들은 GPS기반의 위치를 포함하는 다른 정보들과 함께 상태 보고서를 주기적으로 방송해야 한다. 일련의 지리적으로 분산된 센서들은 이러한 보고서들을 수신하고 그들의 관측들은 크라우드 소싱 방식으로 다른 센서들과 공유되어 진다. 중앙 서버가 추후 관측들을 위해 이를 저장하고 처리한다. 종합적으로, 수신 센서들은 고정적이고 상당히 덜 움직이는 반면에, 우리는 항공기의 매우 높은 이동성을 직면하게 된다. 그림1은 우리가 ADS-B 보고서들의 신뢰성을 평가하기 위해 고려한 시스템 모델의 개요를 보여준다.

4. Considered Adversary

 Our adversary model comprises several prominent attack vectors, which we categorize according to their intended target and their scope. Table $I$ shows an overview. We evaluate our proposed system against these attacks. Moreover, we will argue in Section $VI-C$ that even attackers with complete knowledge about our verification scheme cannot bypass our implementation of wireless witnessing and can still be detected.

 우리의 공격자 모델은 몇가지 두드러지는 공격 백터들로 구성되어있으며, 우리는 그들의 의도된 타겟과 그들의 범위에 따라서 목차화했다. 표 1은 개요를 보여준다. 우리는 이러한 공격들에 대해서 우리가 제안한 시스템을 평가한다. 게다가, 우리는 섹션 6-C에서 심지어 공격자들이 우리의 검증 스키마에 대한 온전한 지식을 가진다 할지라도, 우리의 무선 목격 구현을 우회할 수 없고 여전히 감지된다는 것에 대해서 설명할 것이다.

 GPS Spoofing. The airborne (self)-positioning sensors process received GPS signals from multiple satellites to embed the results in the broadcasted ADS-B reports. One attack scenario considers the spoofing of GPS signals where an attacker sends out specially crafted signals at a considerable signal strength. As a result, an attacker can inject false positioning or timing information into the aircraft systems inducing the processing of fake attacker-controlled data.

 GPS Spoofing. 상공에 있는 위치 센서 프로세스들은 다수의 위성들로부터 GPS 신호들을 받고 방송된 ADS-B 보고서들에 결과를 추가한다. 한 가지 공격 시나리오는 공격자가 상당한 신호 강도로 특수 제작한 신호들을 보내는 GPS 신호들의 Spoofing을 고려할 수 있다. 결과적으로, 공격자는 가짜 위치나 타이밍 정보를 가짜 공격자-제어 데이터를 처리하도록 하면서 항공 시스템에 주입할 수 있다.

 ADS-B Spoofing (Single). An attacker capable of generating fake ADS-B messages can transmit arbitrary reports with full control over their contents. These bogus reports may represent, e.g. any aircraft identifier, positioning solution, or movement information. Receivers of such messages will decode the message contents and forward the sensed information to the central server. We differentiate this attack according to the number of affected sensors. An attacker that is limited in its effective range is likely to only affect single sensors due to their broad spatial distribution.

 ADS-B Spoofing (Single). 가짜 ADS-B 메시지들을 생성하는 공격 능력은 그들의 내용들에 대한 전체적인 제어를 가지는 임의의 보고서들을 전송할 수 있다. 이러한 가짜 보고서들은 예를들어, 항공기 신원, 위치 솔루션, 또는 이동 정보등을 나타낼 수 있다. 이러한 메시지들을 받는 수신자는 메시지 내용을 해독하고 중앙 서버로 의미있는 정보를 전달할 것이다. 우리는 영향을 받은 센서들의 수에 따라서 이러한 공격을 구분한다. 그것의 유효범위가 제한되는 공격자는 그들의 공간 분포가 넓기 때문에 단일 센서에만 영향을 줄 것 같다.

 ADS-B Spoofing (Multiple). A large-scale attacker may also be capable of targeting multiple geographically distributed sensors at the same time. This attacker, however, requires mulitple antennas or a high elevated high power antenna. The attack is conducted in a broadcast fashion and is expected to affect all sensors within its targeted area. As a result, more than one sensor would receive the same fake report and forward it to the central server.

 ADS-B Spoofing (Multiple). 대규모 공격자는 또한 동시에 다수의 지리적으로 분산된 센서들을 타겟으로 할 능력을 가질 수 있다. 하지만, 이러한 공격자는 여러개의 안테나또는 고출력의 안테나를 필요로 한다. 공격은 브로드캐스트 방식으로 실행되며 타겟 영역내의 모든 센서들에 영향을 끼칠 것으로 보인다. 결과적으로, 하나 이상의 센서들이 같은 가짜 보고서를 받을 것이고, 그것을 중앙 서버로 전달할 것이다.

 Sensor Control. Due to the open nature of the surveillance network, attackers may operate their own sensors and become part of the crowdsourcing infrastructure. Having full control over a sensor, an attacker is able to inject arbitrary data encapsulated in genuine ADS-B reports. This attack can be performed without broadcasting any signals and can be directly conducted on the network level.

 Sensor Control. 감시 네트워크의 공개 성질 때문에, 공겨자들은 그들 자신의 센서들을 작동시켜 크라우드 소싱 인프라의 한 부분이 될 수 있다. 센서에 대한 모든 제어를 가지는 것은 공격자가 진짜 ADS-B 보고서들에 캡슐화된 임의의 데이터를 주입할 수 있다. 이러한 공격은 어떠한 브로드캐스팅 신호들 없이도 수행될 수 있고 직접적으로 네트워크 레벨에서 수행될 수 있다.

Sybil Attack. A large-scale attacker operating a significant number of sensors can perform a Sybil attack with the purpose of overruling the network's protection systems. The sensors may be deployed at different locations to influence several redundant views at the same time. This constitutes one of the most powerful attack against sensor networks.

 Sybil Attack. 상당 수의 센서들을 작동시키는 대규모 공격자는 네트워크의 보호 시스템들을 뒤덮을 목적으로 Sybil 공격을 수행할 수 있다. 센서들은 동시에 다양한 중복 보기에 영향을 주기 위해서 다른 위치에 배포될 수 있다. 이것은 센서 네트워크에 대한 가장 강력한 공격들 중 하나이다.

Design of an ADS-B Trust System

 We propose a system to establish a dynamic verification of ADS-B messages for air-traffic surveillance. We first describe the specifics of the analyzed data and state general network statistics. We then define (i) three verification tests checking the contents of a messages and (ii) one ML-based classification of the report metadata, i.e., the reception pattern.

 우리는 항공 교통 관제를 위해서 ADS-B 메시지들의 동적 검증을 구축하기 위한 시스템을 제안한다. 먼저, 분석된 데이터의 세부사항과 일반 네트워크 통계에 대해서 서술한다. 이후 메시지들의 내용을 확인하는 3가지 검증 테스트와 기계학습 기반의 보고서 메타데이터(수신 패턴) 분류기에 대해서 정의한다.

1. Data Source Specifics

 As the source of our considered data, we utilize real-world air-traffic data from the OpenSky Network. The sensors are installed and operated by volunteers, who can either remain anonymous or opt to register by providing personal information. Over 1000 sensors promote the coverage of the network that exhibits a particular high sensor density in Europe and on the American continent. The network relies on user-provided data, processes it on centralized servers, and offers access to the collected data of around 20 billion messages per day. It is noteworthy that nodes in the network are not equipped with any cryptographic means or certificates, which would hinder the growth of the sensor network and contradict the easy access to the crowdsourcing platform. While other air-traffic sensor networks exist, we make use of the research-friendly data sharing of this network.

 우리의 고려된 데이터의 원천에 따르면, 우리는 OpenSky Network로부터 실제 항공 교통 데이터를 활용한다. 센서들은 익명으로 남거나 개인 정보를 제공함으로써 등록하기로 결정한 지원자들에 의해 설치되고 수행된다. 1000개 이상의 센서들은 유럽과 미국 대륙에서 고밀도를 보이는 네트워크의 범위를 촉진시킨다. 네트워크는 중앙 서버들에서 그것을 처리하는 유저-제공 데이터에 의지한다, 그리고 매일 200억개의 수집된 데이터에 대한 접근을 제안한다. 네트워크에 있는 노드들은 센서 네트워크의 성장을 숨기고 크라우드소싱 플랫폼에 대한 쉬운 접근을 부정하는 어떠한 암호학적 의미나 인증서가 장착되어 있지 않다는 점이 주목 할 만하다. 다른 항공 교통 센서 네트워크들은 존재하는 반면에, 우리는 이 네트워크의 연구 친화적 데이터 공유의 사용하도록 만든다.

 For the sake of simplicity, we initially restrict the considered ADS-B reports to the European airspace where the OpenSky Network sensor density is the highest. To further reduce complexity, we divide this space into non-overlapping square shaped clusters $C$ with edge lengths of approx. 10km. In total, the considered environment becomes the union of 232,139 different clusters $C_j \in C$.

 단순성을 위해서, 우리는 OpenSky Network 센서 밀도가 가장 높은 유럽 공역의 ADS-B 보고서들로 제한했다. 복잡성을 더 낮추기 위해서, 우리는 10km의 축적으로 중첩되지 않는 네모 모양 $C$로 영역을 나누었다. 결과적으로 해당 환경은 232,139개의 클러스터($C$)로 나누어 진다.

 In order to get a better understanding of the data provided by the OpenSky Network, we visualize the sensor coverages and the number of processed ADS-B messages with respect to their spatial distribution. These evaluations are based on data collected from an entire data (February 15, 2020) resulting in a total of 132,883,464 messages broadcasted by real aircraft. Figure 2 depicts a heat map of the spatial distribution of all recorded ADS-B reports. As one can see, most reports originated from a few cluster areas close to central European airports. Notably, the database only contains messages that reached at least one contributing sensor.

 OpenSky Network에 의해 제공된 데이터에 대한 더 나은 이해를 돕기 위해서, 우리는 센서 커버리지와 그들의 공간 분포에 따른 ADS-B 메시지들의 수를 시각화 했다. 이러한 평가들은 실제 비행기에 의해 방송되어진 총 132,883,464개의 데이터로(February 15, 2020)부터 수집된 데이터를 기반으로 했다. 그림2는 모든 기록된 ADS-B 보고서들의 공간 분포에 대한 히트맵이다. 그림에서 보이듯이, 대부분의 보고서들은 중부 유럽 공항들과 가까운 몇 개의 클러스터로부터 기원된다. 특히, 데이터베이스는 최소 하나의 센서에 도달한 메시지들만을 포함한다.

 The overall coverage of the network is the combination of all participating sensors. Since sensor coverages can significantly overlap with each other, the redundancy is higher in areas with more sensors as compared to rural areas. Figure 3 shows the aggregated sensor coverage of the OpenSky Network as of February 15, 2020. The heatmap depicts the number of sensors that simultaneously cover an indicated area. A total of 729 different sensors reported data for the considered airspace. We notice a strong dominance in Central Europe, where the most participating sensors are operated. Nevertheless, the coverage of the sensor network also limits the applicability of our system. Airspaces covered by no sensors are not protected.

 네트워크의 전체적인 커버리지는 모든 참가 센서들의 조합이다. 센서 커비리지가 서로서로 상당히 겹치기 때문에, 시골 지역에 비해서 많은 센서들을 가지는 지역에 견고성이 더 높다. 서로 다른 총 729개의 센서들은 해당 공역들을 위해 데이터를 보고했다. 우리는 대부분의 참가 센서들이 수행되고 있는 중부 유럽에서 강한 영향력을 알았다. 그럼에도 불구하고, 센서 네트워크의 커버리지는 또한 우리 시스템의 적용 가능성을 제한한다. 센서에 의해 커버되지 않는 영공들은 보호되지 않는다.

2. Notations

 For the remainder of this paper, we use the following notations. The network is formed by a set of ground-based sensors $S$, where each sensor is referred to as $S_i \in S$. Each ADS-B message $m$ can be received by an arbitrary number $\geq$ 1 of sensors $S_i$, hence the link ($m, S_i$) exists. Due to noise effects and message collisions, message loss can naturally occur and we denote the probability that sensor $S_i$ receives a message transmitted from cluster $C_j$ as $P_{rec}(S_i, C_j)$. Moreover, the messages are timestamped by the receiving sensors, where $t$ is the issued timestamp. When a message is not picked up by any sensor, it is consequently not in the considered database. Table $II$ summarizes the used notations.

 이 논문의 나머지 부분에 대해서, 우리는 다음과 같은 노테이션을 사용한다. 네트워크는 지상 기반 센서 $S$의 집합에 의해 형성된다. 각 센서들은 $S_i \in S$로 표현된다. 각 ADS-B 메시지 $m$은 1 이상의 임의의 개수의 센서 $S_i$에 의해 수신될 수 있다. 따라서, ($m, S_i$)링크가 존재한다. 소음 효과와 메시지 충돌 때문에, 메시지 손실은 자연스럽게 발생할 수 있고 우리는 센서 $S_i$가 클러스터 $C_j$로부터 전송되어진 메시지를 받는 확률을 $P_{rec}(S_i, C_j)$로써 정의한다. 게다가, 메시지들은 수신 센서들에 의해 시간이 기록된다.

3. ADS-B Message Trust

 In order to assess the trustworthiness of ADS-B messages, we design an evaluation process consisting of four verification tests, namely ($i$) sanity, ($ii$) differential, ($iii$) dependency, and ($iv$) cross check. While the former three tests are stated for the sake of completion, we focus on the cross check that is tailored towards the existing sensor infrastructure to implement wireless witnessing. The system overview is depicted in Figure 4 and is developed in the following.

 ADS-B 메시지의 신뢰성을 평가하기 위해서, 우리는 주로 온전성, 차별성, 의존성 그리고 상호 검증인 4가지 검증 테스트로 구성된 평가 절차를 설계한다. 앞의 3가지 검증들은 완료의 목적으로 진행되지만, 우리는 무선 목격을 구현하기 위해 이미 존재하는 센서 인프라에 딱 맞는 상호 검증에 집중한다. 시스템 오버뷰는 그림4에 묘사되어있고 뒤에서 서술한다.

 1) Sanity Check: The sanity check represents a message content verification with respect to defined value ranges. Where data values are not restricted by definition, we apply physical possibility bounds. Sanity checks are specific to the message content, i.e., the reported aircraft status. Table $III$ provides an overview of the implemented sanity check.

  1) 온전성 검사: 온전성 검사는 정해진 값의 범위에 대하여 메시지 내용 검증을 의미한다. 데이터 값들이 정의에 의해 제한되지 않는다면, 우리는 물리적 가능 범위를 적용한다. 온전성 검사들은 메시지 내용, 즉 보고된 항공기 상태에 따라 다르다. 표 3은 구현된 온전성 검사의 오버뷰를 제공한다.

Position. The reported position contains information about the latitude, longitude, and altitude. The latitude is only defined in the range of -90$\degree$ to 90$\degree$, whereas the longitude is defined over -180$\degree$ to 180$\degree$. The altitude is not bounded by its definition but by physical restrictions ranging from approx. -3m, which is the altitude of the lowest European airport, Amsterdam Airport Schipholl. For the maximal altitude, we use a bound of 20,000m, which is hardly reachable for casual air traffic.

위치. 보고된 위치는 위도, 경도, 그리고 고도에 대한 정보를 포함한다. 위도는 오직 -90$\degree$ 에서 90$\degree$까지의 범위만을 정의한다, 반면에 경도는 -180$\degree$ 에서 180$\degree$까지 정의한다. 고도는 정의에 의해서 제한되지 않지만, 가장 낮은 유럽 공항(Amsterdam Airport Schipholl)의 고도인 -3m 범위로부터 물리적인 규제에 의해 정의된다. 최대 고도를 위해서, 20,000m의 범위를 사용한다. 이는 일반 항공 교통에 대해 도달 할 수 없다.

Movement. While airborne, the velocity is expected to be positive and bounded by the maximal speed of the specific aircraft type, usually less than approx. 1,200km/h. The direction of movement, referred to as the true track, is defined by the angle aligned with the True North in the range of 0$\degree$ to 360$\degree$. Moreover, the vertical rate is also aircraft-dependent and is expected to not exceed $\pm50 m/s$.

이동 방향. 하늘에 있는 동안에, 속력은 양수가 되고, 특정 항공기 유형의 최대 속도인 대략 1,200km/h보다 낮은 속도로 제한될 것으로 예상된다. 실제 트랙을 의미하는 이동 방향은 0$\degree$ 에서 360$\degree$의 범위에서 True North와 정렬된 각도로 정의된다. 게다가, 수직 속도 또한 항공기에 따라 다르고 $\pm50 m/s$를 넘지 않을 것으로 예상된다.

Identification. Each aircraft is assigned a unique identification, the ICAO 24-bit registration identity. This identifier can be checked against databases that contain currently assigned ICAO registrations. In addition, each aircraft is assigned a volatile call sign, which can also be verified.

신원 확인. 각 항공기는 ICAO 24비트 등록 번호라 불리는 고유 ID를 할당받는다. 이 ID는 현재 할당된 ICAO 등록을 포함하는 데이터베이스에 대해 검사할 수 있다. 게다가, 각 항공기는 휘발성의 호출 부호를 할당 받는데, 이 또한 검증될 수 있다.

 2) Differential Check: The differential check considers changes between succeeding ADS-B messages from the same aircraft. These checks, therefore, require the assignment of messages to tracks based on the included identifier. In consideration of the message update rate and broadcast frequency, we identify reasonable maximal changes per second that conform to the inertia and aircraft capabilities as well as covered by observations of real flight data. Table $IV$ contains the implemented tolerable parameter changes. In cases where we receive updated ADS-B reports after a prolonged loss of communication, e.g., due to missing sensor coverage, we incorporate the lack of data by scaling the tolerable maximal change with the missed time period.

 2) 차별성 검사: 차별성 검사는 같은 항공기로부터 온 계속적인 ADS-B 메시지의 차이점을 검사한다. 그러므로, 이러한 검사들은 내재된 ID를 기반으로 경로에 대한 메시지들의 할당을 요구한다. 메시지의 업데이트 속도와 방송 주파수를 고려하여, 우리는 관성과 항공기 기능들에 부합하는 합리적인 초당 최대 변화를 식별하고 실제 항공 데이터의 관측을 통해 다룬다. 표 4는 구현된 허용되는 파라미터 변화를 포함한다. 센서 커버리지를 잃어버리는 장기적인 통신의 손실 이후에 업데이트된 ADS-B 보고서를 받는 상황에서, 우리는 놓친 시간 동안에 허용 최대 변화를 확장함으로써 데이터의 부족을 통합한다.

 3) Dependency Check: The dependency check verifies the relationship between physically-dependent parameters of subsequent reports from the same aircraft. We validate reported horizontal and vertical changes based on predictions of the next position and allow for a tolerance up to 100m, which we have empirically derived from the available dataset. A further dependency exists between the reported altitude and the aircraft indicating to be on ground. We coarsely perform this check against the elevation of the highest European airport (1,707 m), Samedan Airport of Switzerland. Notably, more fine-grained information about the geographical topology would greatly benefit the validity. Table $V$ shows the implemented dependency checks.

  3) 의존성 검사: 의존성 검사는 같은 항공기로부터 후속 보고서의 물리적으로 의존하는 파라미터들 간의 관계를 검증한다. 우리는 다음 위치에 대한 예측을 기반으로 보고된 수평적, 수직적 변화들을 검증하고, 가능한 데이터 세트로부터 경험적으로 도출한 최대 100m 까지 허용 오차를 허용 한다. 추가 의존성은 보고된 고도와 땅 위에 있다고 표시되는 항공기들 사이에 존재한다. 우리는 가장 높은 유럽 공항(1,707m)인 스위스의 Samedan Airport의 단계에 대해서 이러한 검사를 거칠게 수행한다. 지리적 토폴로지에 대하여 잘 정제된 정보는 유효성에 이득을 준다. 표 5는 구현된 의존성 검사를 보여준다.

 4) Cross Check: The cross check utilizes the spatial redundancy of the surveillance network in a collaborating manner. Participating sensors are widely distributed and their coverages overlap significantly, as shown in Figure 3. Even though the sensor locations are unknown, we can determine which sensors observe which airspace via inspecting the reported positions embedded in their received ADS-B reports. Hence, in our grid-based approach, each cluster $C_j$ is dedicated to covering sensors $S_i$ such that the following equation holds: $$ P_{rec}(S_i, C_j) > 0 \qquad(1) $$

  4) 교차 검사: 교차 검사는 공동 작업 방식으로 감시 네트워크의 공간 중복성을 활용한다. 참가 센서들은 널리 분산되어 있고 그림3에서 보듯이, 그들의 커버리지는 상당히 중복된다. 비록 센서 위치가 알려져있지 않더라도, 우리는 그들의 수신된 ADS-B 레포트들에 포함된 보고된 위치를 검사하여 어떤 센서들이 어떤 공역을 감시하는지 결정할 수 있다. 더군다나, 우리의 그리드 기반의 접근방식에서 각 클러스터 $C_j$는 다음과 같은 공식을 유지하도록 센서 $S_i$를 커버하는데 전념한다. $$ P_{rec}(S_i, C_j) > 0 \qquad(1) $$

 If multiple sensors $S_i$ cover the same cluster $C_j$ such that $P_{rec}(S_i, C_j) > 0$, we can countercheck received message by consulting all designated sensors. For each sensor that covers a reported aircraft position, we distinguish two discrete events the sensor has received the message or the sensor has not received the message: $$ X_{m, S_i}= \begin{cases} 0\quad\nexists(m, S_i) \ 1\quad\exists(m, S_i) \end{cases} \qquad(2) $$

만약, 여러개의 센서들이 $S_i$ 같은 클러스터를 $C_j$ 커버하고 있다면, $P_{rec}(S_i, C_j) > 0$, 우리는 모든 지정된 센서들을 고려함으로써 수신된 메시지들을 상호 검사할 수 있다. 보고된 항공기 위치를 커버하는 각 센서들을 위해서, 우리는 센서들이 메시지를 수신 했는지 또는, 수신 하지 못했는지에 대한 2가지 이벤트를 구분한다. $$ X_{m, S_i}= \begin{cases} 0\quad\nexists(m, S_i) \ 1\quad\exists(m, S_i) \end{cases} \qquad(2) $$

 Due to noise effects and signal collisions, sensors naturally experience a message loss in the range of 10% to 75% depending on the distance to the origin, obstacles in view, and the airspace density. Hence, the case of missing a report does not causally imply unusual behavior or the existence of attacks and needs to be factored in accordingly. We refer to the combination of events $X_{m,S_i}$, $S_i \in S$ as the observed message reception pattern for a report broadcasted from the claimed position. Each sensed message is therefore mapped to a vector representing the reception events for every sensor: $$ \vec{X}m = [X{m,S_1}, X_{m,S_2},...,X_{m,S_{n-1}}, X_{m,S_n}] \qquad(3) $$

노이즈 효과와 신호 충돌 때문에, 센서들은 기원으로부터의 거리, 가시거리의 장애물, 공역 밀도에 따라서 10%에서 75%까지의 메시지 손실을 경험한다. 더군다나, 보고서를 잃어버리는 경우에는 비정상 행동이나 공격의 존재를 암시할 수 없으므로 이에 대한 고려가 필요하다. 우리는 보고서를 위해 관찰된 메시지 수신 패턴이 요청된 위치로부터 방송되어지는 것으로써 이벤트들의 조합($X_{m,S_i}$, $S_i \in S$)을 정의한다. 각 감지된 메시지는 모든 센서를 위해 수신 이벤트들을 의미하는 벡터에 매핑된다. $$ \vec{X}m = [X{m,S_1}, X_{m,S_2},...,X_{m,S_{n-1}}, X_{m,S_n}] \qquad(3) $$

 where n is the total number of sensors in the network. For our considered scenario, we obtain a vector with 729 entries, which represents the message reception pattern. These patterns exhibit a certain variance and cannot be translated into fixed rules due to non-deterministic sensor reception. Hence, we choose a Machine Learning (ML) approach to handle the huge amount of available data and simultaneously consider unknown external effects.

 n은 네트워크에 존재하는 센서들의 총 개수이다. 우리의 고려된 시나리오에 대하여, 우리는 메시지 수신 패턴을 나타내는 729개의 엔트리를 가지는 벡터를 얻는다. 이러한 패턴들은 특정 분산을 나타내고 비결정론적인 센서 인식때문에 고정 규칙으로 변화되지 않는다. 게다가, 우리는 많은 양의 가용가능한 데이터를 다루고 동시에 알려지지 않은 외부 요인을 고려하기 위해서 기계 학습(ML)방식을 선택했다.

 In particular, for each of the 132,883,464 recorded ADS-B reports, we determine which of the 729 sensors reported that specific message. In combination with the embedded positioning information, we learn typical reception patterns for the entire day and label the data to be the result of normal operating air traffic and sensors. After processing all reports, each cluster $C_j$ is assigned with actually observed message reception patterns and we assume these patterns to represent normal behavior. We discuss this assumption in Section $VI-A$ and reason about its validity.

 특히, 기록된 각 132,883,464개의 ADS-B 보고서들에 대하여, 우리는 729개의 센서들 중 특정 메시지를 기록하는 센서가 어떤 것인지 결정한다. 내재된 위치 정보의 조합과 함께, 우리는 하루 종일 전형적인 수신 패턴을 학습하고 일반적인 항공 교통과 센서들의 작업의 결과로 데이터를 라벨링 한다. 모든 보고서들을 처리한 후에, 각 클러스터 $C_j$들은 실제로 관측된 메시지 수신 패턴으로 할당되어지고 우리는 이러한 패턴을 정상 행위로 나타내기 위해서 추측한다. 우리는 섹션 6-A에서 이러한 가정에 대해 논의하고 그것의 유효성에 대한 이유를 설명한다.

Algorithm Choice. Since our feature space is defined by the number of sensors and each feature is limited to either be 0 (not received) or 1 (received), we choose to use Decision Trees (DTs). This choice is in accordance with similar work classifying distributed sensor events. For more information on machine learning algorithms, we refer to an article by Leo Breimann.

알고리즘 선택. 우리의 특징 영역이 센서들의 수에 의해 정의되어지고 각 특징들이 0 (수신 받지 못함)이나 1 (수신 받음)로 제한되기 때문에, 우리는 의사 결정 트리(DTs)를 사용하기로 결정했다. 이 선택은 분산 센서 이벤트들을 분류하는 유사한 작업에 따른 것이다. 기계 학습 알고리즘에 대한 더 많은 정보는 Leo Breimann의 기사를 참고해라.

4. Attack Analysis

 In the case where at least one of our verification tests indicates unusual behavior, an attack analysis is triggered that tries to further reason about $(i)$ the type of attack and $(ii)$ the affected sensors. Depending on which test triggered the attack analysis, different conclusions can be drawn on the cause of an alarm.

 우리의 검증 테스트들 중 최소 하나라도 비정상 행동을 보이는 상황에서, 공격 분석은 $(i)$공격의 유형과 $(ii)$영향을 받은 센서들에 대한 추가적인 추론을 시도하는 트리거가 발생한다. 어떤 테스트가 공격 분석을 트리거했는지에 따라서, 알람의 원인에 대한 다른 결과들이 도출될 수 있다.

 1) Type of Attack: We notice that our three attack classes, i.e., GPS spoofing, ADS-B spoofing, and sensor control/Sybil attack, can be characterized by the type of manipulation they cause on the message, respectively on the network. This can either be on the content of the ADS-B messages directly, or more subtle on the message reception characteristic. While the sanity, differential, and dependency checks can verify the message payload, the cross check evaluates the reception pattern. For each attack vector, we identify which verification test is indicative and provide an overview in Table $VI$.

 1) 공격의 유형: 우리의 3가지 공격 클래스들(GPS spoofing, ADS-B spoofing, sensor control/Sybil attack)은 각각의 네트워크에서 메시지에 대한 조작 유형에따라 특징화 될 수 있다는 것을 안다. 이는 ADS-B 메시지의 내용에 대해 직접적으로 행해질 수 있다. 온전성, 차별성, 의존성 검사가 메시지 페이로드를 검증할 수 있는 반면에, 상호 검증은 수신 패턴을 평가한다. 각각의 공격 벡터에 대하여, 우리는 어떤 검증 테스트가 직설적인지 확인하고 표 6에서 오버뷰를 제공한다.

Sanity Check. The sanity check detects defined value range violations. These can occur when a report is either specifically crafted during an ADS-B spoofing attack or if a sensor is entirely under the control of an attacker.

온전성 검사. 온전성 검사는 정의된 값의 범위의 위반을 감지한다. 이것들은 레포트가 ADS-B spoofing 공격 동안에 특정하게 생성되었거나, 센서가 온전히 공격자의 통제하에 있을 경우에 발생할 수 있다.

Differential Check. The differential check is indicative to unusual jumps in the data. A GPS spoofing attack may hence be detectable if the position exhibits a sudden jump. All other attacks may also trigger an alarm depending on the variance in the generated fake data.

차별성 검사. 차별성 검사는 데이터 내에서 일반적이지 않은 점프를 나타낸다. GPS spoofing 공격은 위치가 갑작스러운 점프를 보여준다면, 감지될 수 있다. 모든 다른 공격들은 생성된 가짜 데이터의 변화에 따라 알람을 트리거할 수 있다.

Dependency Check. The dependency check detects inconsistencies between dependable data from independent sensors within the aircraft. Since a successful GPS spoofing attack only affects GPS-related sensors, other information on the movement or on the heading will likely result in a violation. Again, other attacks may also fail this test if the fake reports do not satisfy parameter dependencies.

의존성 검사. 의존성 검사는 항공기 내에 있는 독립적인 센서로부터 신뢰할 만한 데이터간의 불규칙성을 감지한다. 성공적인 GPS spoofing 공격은 오직 GPS와 관련된 센서들에만 영향을 주기 때문에, 이동이나 방향에 관련된 다른 정보들은 위반으로 이어질 가능성이 높을 것이다. 다시 말하지만, 가짜 레포트들이 파라미터 의존성을 만족하지 못한다면, 다른 공격들은 또한 이러한 검사들을 실패할 것이다.

Cross Check. The cross check tries to decide if a message reception pattern is the result of normal behavior or not. An aircraft report affected by a GPS spoofing attack indicates a wrong position and the reception pattern will likely differ from the actual reception pattern of the real location. For the other attacks, the validity of the cross check depends upon the number of benign sensors that observe the claimed aircraft position. The more sensors simultaneously cover an area, the less likely it will be that only a specific number of sensors, e.g., affected by an ADS-B spoofing attack, receive the specific message. Similar considerations apply for attackers adding sensors to the network. Unaffected sensors will not report injected messages which is eventually reflected in an unusual reception pattern. For both attack classes, reception patterns are easier to decide the more sensors are participating.

상호 검증. 상호 검증은 만약 메시지 수신 패턴이 정상 행동의 결과인지 아닌지 결정한다. GPS spoofing 공격에 영향을 받은 항공기 레포트는 잘못된 위치를 나타내고 수신 패턴이 실제 위치의 실제 수신 패턴과 다를것이다. 다른 공격들에 대하여, 상호 검증의 유효성은 요청된 항공기 위치를 관측하는 정상 센서들의 수에 달려있다. 더 많은 센서들이 동시에 지역을 커버한다면, 더 적은 특정 수의 센서들(ADS-B spoofing 공격에 의해 영향을 받은)만이 특정 메시지를 수신할 것이다. 공격자들이 네트워크에 센서를 추가하는 것도 비슷한 고려사항이 적용된다. 영향을 받지 않은 센서들은 주입된 메시지들을 보고하지 않을 것이며 이는 결국 비정상적인 수신 패턴에 영향을 줄것이다. 양쪽의 공격 클래스들에 대하여, 수신 패턴들은 더 많은 센서들이 참가하는 것을 결정하기에 쉬울 것이다.

 2) Affected Sensors: If we successfully detect unusual behavior and identify the type of attack, we try to also reason about the affected ADS-B sensors. We generally distinguish between passively and actively participating sensors during an attack. While we can tag all sensors that reported an untrustworthy message as potentially malicious, we are interested which sensors are indeed under the attacker's control. Theses compromised sensors are actively trying to disrupt the network. We, therefore, identify all sensors that report messages clearly assigned to a sensor control/Sybil attack as malicious. Their identification allows the disconnection from the network and to restore the network's integrity.

 2) 영향을 받은 센서들: 만약 우리가 비정상 행동을 성공적으로 탐지하고 공격의 유형을 식별한다면, 영향을 받은 ADS-B 센서들인지에 대하여 설명하려 할 것이다. 우리는 공격 동안에 참가 센서들이 미활동중인지 활동중인지 구분한다. 비신뢰 메시지를 보고하는 모든 센서들을 우리가 잠재적으로 위협으로 태그할 수 있는 반면에, 우리는 어떤 센서들이 실제로 공격자의 제어 아래에 있는지 궁금해한다. 이러한 오염된 센서들은 네트워크를 방해하려고 적극적으로 노력한다. 그러므로, 우리는 센서 제어/시빌 공격에 대하여 명확하게 할당되어 있는 메시지를 보고하는 모든 센서들을 위협으로 식별한다. 그들의 식별 때문에 네트워크로부터의 연결 해제와 네트워크의 무결성을 복구할 수 있다.

 On the other hand, sensors that fell victim to an attack themselves may only be temporarily disconnected from the network. Sensors that are recognized in such a way can later be reactivated once the attack is over. The tracing of affected sensors also allows for a coarse localization of an attack. Even though sensor locations are unknown, coverages of the sensors can be determined and consequnetly a rough attacker position could be narrowed down.

 반면에, 공격의 희생양이 된 센서들은 일시적으로 네트워크로부터 연결 해제될 것이다. 그러한 방법으로 인식된 센서들은 후에 일단 공격이 끝나면 재활성화될 수 있다. 영향을 받은 센서들의 추적은 또한 공격의 대략적인 위치를 알아낼 수 있다. 센서 위치들을 알 수 없을지라도, 센서들의 커버리지들은 결정될 수 있고, 결과적으로 공격자 위치를 좁힐 수 있다.

Simulation

 While the characteristics of normally operation air traffic can be learned from the actually received ADS-B reports, attack scenarios are required to be emulated based on realistic assumptions and experience. Assuming that no attacks were launched on the selected day (February 15, 2020), we use all reports to map typical reception patterns. In the following, we describe how we simulated the three considered attack classes, i.e., GPS spoofing, ADS-B spoofing, and sensor control/Sybil attack. For each attack, we generate at least the number of reports as received normally, i.e., more than 132 million different fake reports representing each respective attack. Note that this does not reflect the actual distribution between normal and attack reports, but is chosen to establish a reasonable database of fake reports. This allocation is used for the training process only.

 정상적으로 수행되는 항공 교통의 성격은 실제로 수신받은 ADS-B 보고서들로부터 학습될 수 있는 반면에, 공격 시나리오들은 실제같은 가정과 경험을 기반으로 에뮬레이트 될 필요가 있다. 공격들은 특정 날짜에 실행되지 않는다고 가정하면서, 우리는 전형적인 수신 패턴을 매핑하기 위해서 모든 보고서들을 사용한다. 다음에서, 우리가 어떻게 세 가지 고려되는 공격 클래스들(GPS spoofing, ADS-B spoofing, and sensor control/Sybil attack)을 시뮬레이션 했는지 설명한다. 각 공격에 대하여, 우리는 정상적으로 수신한 최소 보고서의 개수, 즉 각 공격을 나타내는 1억 3,200만개의 서로 다른 가짜 보고서들을 생성한다. 이것이 정상 보고서와 공격 보고서 간의 실제 분산을 반영하지 않는다는 것을 유의해라. 하지만, 가짜 보고서들의 합리적인 데이터베이스를 구축하기위해 선택되었다. 이러한 할당은 오직 학습 과정만을 위해서 사용되었다.

1. GPS Spoofing

 To emulate a successful GPS spoofing attack, we manipulate the reported GPS-derived positioning information embeded in ADS-B reports. More precisely, we randomly sample one ADS-B report from the entire dataset. We then gather all reports from the corresponding aircraft for the preceding 15 min and the next 60 min representing a 75 min aricraft track. This track is then subject to selected deviations $\alpha$ of 1$\degree$, 2$\degree$, 5$\degree$, 10$\degree$, 20$\degree$, or 45$\degree$ to simulate an attack incrementally leading aircraft off their track starting at $t_{attack}$ = 15 min. Figure 5 depicts this procedure. For each deviation, we replace the GPS position in the reports while all other data fields and the sensors that received the message remain the same. We label the messages as resulting from a GPS spoofing attack after $t_{attack}$ and also keep track of the applied deviation, the distance to the original track, and the elapsed time after the attack has been launched. We repeat this process of randomly sampling reports from the dataset and manipulating the GPS position until the desired number of reports is reached.

 성공적인 GPS spoofing attack을 실험하기 위해서, 우리는 ADS-B 보고서들에 내재된 GPS 기반의 위치 정보를 조작한다. 더욱 정확하게는, 우리는 전체 데이터베이스에서 무작위하게 하나의 ADS-B 보고서 표본을 추출한다. 그러고 나서 우리는 이전 15분과 75분간의 항공 경로를 나타내는 다음 60분동안 해당 항공기에서 모든 보고서들을 수집한다. 항공기가 $t_{attack}$ = 15 min에서 수행되는 점진적으로 그들의 경로를 벗어나는 공격을 시뮬레이션 하기 위해서, 이 경로는 특정 편차 $\alpha$(1$\degree$, 2$\degree$, 5$\degree$, 10$\degree$, 20$\degree$, or 45$\degree$)를 가진다. 그림 5는 이러한 절차를 묘사한다. 각 편차에 대하여, 우리는 다른 모든 데이터 필드와 메시지를 수신하는 센서들이 같게 유지되는 동안에 보고서들에 있는 GPS 위치를 교체한다. 우리는 $t_{attack}$이후에 GPS spoofing attack의 결과로써 메시지들을 라벨링하고 적용된 편차의 경로, 원래 경로와의 거리, 그리고 공격이 수행된 이후 경과된 시간을 보관한다. 우리는 데이터베이스로부터 무작위하게 보고서들을 추출하고 GPS 위치를 조작하는 이 과정을 목표된 보고서의 수에 도달할 때까지 반복한다.

2. ADS-B Spoofing

 When simulating an ADS-B spoofing attack, we are faced with the problem of unknown sensor locations. Even the tracing of observed clusters does not reveal a sensor position since the reception range can highly vary and may be distinct in different directions. It is noteworthy that an attacker would face the same problem and cannot pinpoint sensors but would need to bindly affect larger regions when targeting multiple senosrs. We differentiate the attack according to how many sensors fall victim to the attack, i.e., a single sensor, multiple sensors, or all sensors within a selected region. Figure 6 illustrates these attacks. To simulate an attacker targeting multiple sensors, we randomly pick sensors up to the average number of observing sensors of the respective cluster.

 ADS-B spoofing attack을 시뮬레이션 할 때, 우리는 알 수 없는 센서 위치 문제를 직면한다. 심지어 클러스터들을 추적하더라도, 수신 범위가 매우 다양할 수 있고 방향이 다를 수 있기 때문에 센서의 위치가 드러나지 않는다. 공격자가 같은 문제를 직면하고 센서들의 위치를 잡을 수 없지만, 다수의 센서들을 목표로 할 때 넓은 지역에 구속력 있게 영향을 줄 필요가 있다는 것에 주목할 만하다. 우리는 얼마나 많은 센서들이 공격의 희생양이 되었는지(단일 센서, 다수 센서, 특정 지역의 모든 센서들)에 따라서 공격을 구분한다. 그림 6은 이러한 공격들을 나타낸다. 다수 센서들을 목표로하는 공격자를 시뮬레이션 하기 위해서, 우리는 각 클러스터의 관측 센서들의 평균 수 만큼 무작위하게 센서들을 고른다.

 We again generate fake messages for each scenario by randomized sampling from real-world aircraft reports. We extract the corresponding 75 min long track and adjust the receiving sensors depending on the coverage of the considered cluster and how many sensors are affected by the attack. All other data fields remain the same. We use real aircraft reports to represent an attacker trying to inject authentic ghost aircraft into the network by sending those messages to the scenario-dependent number of sensors.

 우리는 실제 항공기 보고서에서 무작위 샘플링을 통해 각 시나리오에 대한 가짜 메시지를 다시 생성한다. 우리는 해당 75분 길이의 트랙을 추출하고 고려된 클러스터의 커버리지와 공격의 영향을 받는 센서의 수에 따라 수신 센서를 조정한다. 다른 모든 데이터 필드는 동일하게 유지된다. 우리는 실제 항공기 보고서를 사용하여 시나리오에 따라 달라지는 센서 수에 해당 메시지를 전송하여 실제 유령 항공기를 네트워크에 주입하려는 공격자를 나타낸다.

3. Sensor Control/Sybil Attack

 In a sensor control/Sybil attack, an attacker adds sensors to the network that are under the attacker's synchronized control. We assume that the attacker's sensors initially behave normally to remain unnoticed prior to any fake message injection. When an attack is launched, all controlled sensors mutually try to report the same fake message. We again differentiate between the number of controlled sensors with regard to the number of benign sensors, i.e., a single sensor or equality between the attacker's sensors and benign sensors.

 sensor control/Sybil Attack에서, 공격자는 공격자의 동기화된 통제하에 있는 네트워크에 센서들을 추가한다. 우리는 공격자의 센서들이 어떠한 가짜 메시지 주입 이전에 알아차려지지 않은 채로 남기위해서 초기에 정상적으로 행동하는 것으로 가정한다. 공격이 시작될 때, 모든 통제된 센서들은 서로 같은 가짜 메시지를 보고하려고 한다. 우리는 단일 센서나 공격자의 센서들과 정상 센서들간의 동일성과 같은 정상 센서들의 수에 따라서 통제된 센서들의 수를 구분한다.

 The process of sampling and selecting tracks is the same as for ADS-B spoofing. We assume that the attacker utilizes all controlled sensors to inject the same message. Notably, the benign sensors that cover the same area are not affected by a Sybil attack and will consequently not report the injection of such messages.

 트랙들을 샘플링하고 선택하는 과정은 ADS-B spoofing을 위한 것과 같다. 우리는 공격자가 같은 메시지를 주입하기 위해서 모든 통제된 센서들을 활용한다고 가정한다. 같은 지역을 커버하는 정상 센서들은 Sybil attack에 영향을 받지 않고, 그러한 메시지들의 주입을 보고하지 않는다는 점에 주목해라.

Evaluation

 We split the evaluation of the developed ADS-B trust system into $(i)$ performance of detecting each considered attack, $(ii)$ distinguishing between attack vectors, $(iii)$ identifying affected sensors, $(iv)$ analyzing the impact of different grid resolutions, $(v)$ investigating the time dependency and $(vi)$ estimating the computational performance.

 우리는 제안된 ADS-B 신뢰 시스템의 평가를 $(i)$ 각 고려된 공격 탐지의 성능, $(ii)$ 공격 벡터들간의 구분, $(iii)$ 공격 받은 센서들의 식별, $(iv)$ 다양한 그리드 해상도의 영향 분석, $(v)$ 시간 의존성 검사, 그리고 $(vi)$ 계산 성능 추정으로 나눈다.

1. Attack Detection Performance

 We approach the attack detection performance in two different ways. First, we consider the classification results of single ADS-B reports without linking consecutive reports, and second, we make decisions on combined aircraft tracks. The training process uses all reports of the selected day as well as the simulated attack vectors based on randomly sampled 75 min long aircraft tracks from the OpenSky Network database according to Section IV. Our attack detection evaluation prototype uses clusters $C_j$ with edge lengths of 10km. We assign each report to its originating cluster indicated by the embedded position splitting up all messages over the observed area. We then perform training with our selected DT classifier by iterating through all clusters.

 우리는 서로 다른 2가지 방식으로 공격 탐지 성능 측정에 접근했다. 첫째는, 연이은 레포트들을 연결하는 것 없이 단일 ADS-B 보고서들의 결과를 분류하는 것을 고려했다. 둘째, 결합된 항공기 트랙들에 대해 의사결정했다. 학습 과정은 선택된 날짜의 모든 보고서들 뿐만 아니라, 섹션 IV에서 언급한 the OpenSky Network 데이터베이스로부터 무작위하게 샘플링된 75분간의 항공기 트랙을 기반으로 한 시뮬레이션된 공격 벡터들을 사용한다. 우리의 공격 탐지 평가 프로토타입은 10km의 테두리 길이를 가지는 클러스터들($C_j$)을 사용한다. 우리가 각 보고서를 관측 영역에서 모든 메시지를 분할하는 내재된 위치에 의해서 표시되는 원래 클러스터들에 할당한다. 그러고나서 우리는 모든 클러스터들을 반복적으로 DT 분류기로 학습한다.

 For testing, we again query the database for 1000 untrained and randomly selected aircraft tracks. We do not make any restrictions on the selection process except that we require that at least 50% of the broadcasted reports are actually recorded by the network. This filters tracks that would quickly leave the covered area, i.e., the scope of the network, and hence cannot be classified due to missing reports. We apply the different attack vectors, label each track accordingly, and then classify the resulting reports with the classifier for the designated cluster. For our three attack classes, i.e., GPS spoofing, ADS-B spoofing, and sensor control/Sybil attack, we shortly describe which test triggers an alarm and then focus on the ML supported cross check providing True Positive Rates(TPRs) and False Positive Rates (FPRs).

 테스트를 위해서, 우리는 다시 1000개의 학습되지 않고, 무작위하게 선택된 항공 트랙을 위해서 데이터베이스에 쿼리를 보낸다. 우리는 방송된 보고서들에 대해서 최소 50%가 실제로 네트워크에 의해서 기록되어야한다는 점을 제외하고는 선정 과정에 관해서 어떠한 제한도 두지 않는다. 이 조건은 커버되는 영역(네트워크의 범위)을 빠르게 떠날 수 있는 트랙을 필터링하기 때문에 누락된 보고서들때문에 DT를 사용할 수 없는 보고서들을 제외한다. 우리는 서로 다른 공격 벡터들을 적용하고, 각 트랙에 따라서 레이블을 지정한 다음, 지정된 클러스터들에 대한 분류기로 결과 보고서들을 분류한다. 우리의 세가지 공격 클래스들(GPS spoofing, ADS-B spoofing, and sensor control/Sybil attack)을 위해서 우리는 간단하게 어떤 테스트가 알람을 트리거하는지 설명하고, TPR과 FPR을 제공하는 ML기반의 상호 검증에 집중한다.

 1) GPS Spoofing: While an incremental position deviation passes the differential check, our dependency check consistently indicates mismatches between predicted positions and the reported GPS position. Even though we account for a specific uncertainty threshold, at one point in time, the attack exceeds this threshold. In consideration of the cross check, the intuition is that the further away an aircraft claims to be from its real position, the more different the reception pattern will be. Notably, the selected cluster for the cross check is determined by the reported/claimed position. If the real position and the spoofed position are still within the same cluster, the reception patterns are the same and a decision towards the presence of a GPS spoofing attack is not possible.

 1) GPS Spoofing 증가하는 위치 편차가 차별성 검사를 통과하는 반면에, 우리의 의존성 검사는 예측된 위치와 보고된 GPS 위치간에 불일치를 일관되게 나타낸다. 심지어 구체적인 불확실성 임계값을 고려하더라도 한 시점에서의 공격은 이 임계값을 넘어선다. 상호 검증을 고려할 때, 항공기가 실제 위치로부터 점점 더 멀어질 수록, 더 많은 수신 패턴이 달라질 것이라는 직감이 든다. 상호 검증을 위한 선택된 클러스터는 보고된/주장하는 위치에 의해서 결정된다는 것에 유의하라. 만약 실제 위치와 변조된 위치가 여전히 동일한 클러스터내에 있다면, 수신 패턴들은 같고 GPS spoofing attack의 존재에 대한 결정은 불가능하다.

 To assess our detection performance of GPS spoofing attacks, we consider a classifier that has been trained with samples from normal operation and the simulated GPS spoofing reports. We further calculate a score based on the classifier outcome and the total number of reports. Following this metric, a score of 1 means that every report is labeled authentic while a score of 0 means that every report was labeled malicious. We evaluate $(i)$ the average score over all 1000 runs of the classifier with respect to different deviations $\alpha$ from the original track and the elapsed time in Figure 7 and $(ii)$ the average score with respect to the distance to the original track in Figure 8. The distance to the original track is a combination of the applied deviation and the time that has elapsed after the launch of the attack.

 GPS spoofing attacks에 대한 우리의 탐지 성능을 평가하기 위해서, 우리는 정상 수행과 시뮬레이션된 GPS spoofing 보고서들로부터의 표본들로 학습된 분류기를 고려한다. 우리는 분류 결과와 보고서의 총 개수를 기반으로 점수를 계산한다. 다음의 측정법에 따르면, 1점은 모든 보고서가 진짜로 라벨링 되었고 0점은 모든 보고서가 악의적이라고 라벨링 되었다는 것을 의미한다. 우리는 그림7에 $(i)$원래의 트랙으로부터 다른 편차들($\alpha$)과 경과 시간을 이용한 분류기의 1000번의 실행에 대한 평균 점수와 그림8에 $(ii)$원래 트랙에 대한 거리에 따른 평균 점수를 평가한다. 원래 트랙으로부터의 거리는 적용된 편차와 공격이 실행된 이후에 경과된 시간의 조합이다.

Results. While the dependency check is effective in detecting GPS spoofing attacks, in cases where additional information might be missing, the cross check is sufficient to detect such attacks with a high probability after a certain amount of time has passed, see Figure 7. For instance, considering $\alpha = 2\degree$, $\alpha = 10\degree$, $\alpha = 45\degree$ the score falls below 0.5 after approx. 20 min, 5 min, and 1 min, respectively. The rate at which the average score decreases is dominated by the applied deviation $\alpha$. The higher the deviation, the faster the fake positions approach other clusters, leading to mismatches in the reception patterns. Notably, the average score, even under normal operation, never reaches 1 due to a portion of reports being wrongly classified. We will handle this problem by linking successive reports when deciding aircraft tracks.

결과. 의존성 검사는 GPS spoofing attacks을 탐지하는데에 효과적인 반면에, 추가적인 정보가 누락되는 경우에서 상호 검증은 특정 시간이 지난 후에, 높은 확률로 이러한 공격들을 탐지하는데에 충분하다. 그림 7 참고. 예를 들어서, $\alpha = 2\degree$, $\alpha = 10\degree$, $\alpha = 45\degree$를 고려하면, 점수는 각각 20분, 5분, 그리고 1분 후에 대략 0.5 밑으로 떨어진다. 평균 점수가 감소하는 비율은 적용된 편차($\alpha$)에 의해 다르다. 편차가 클 수록, 가짜 위치들이 다른 클러스터들에 더 빠르게 접근하여 수신 패턴이 불일치한다. 심지어 정상 수행이더라도, 평균 점수는 잘못 분류된 일부 보고서들로 인해 1점에 다다를 수 없다는 것에 유의하라. 우리는 이러한 문제를 항공기 트랙을 결정할 때, 연속적인 보고서들을 연결함으로써 해결한다.

 Figure 8 condenses the deviation and the elapsed time into the distance to the original track. The average score quickly approaches 0.5 for distances up to one grid reolution, i.e., 10km in our evaluation prototype. After this point has been reached, the decline slows down and reaches approx. 0.35 for a distance of two grid resolutions. Further distances only moderately decrease the average score and it nearly stabilizes at this point. We observe that the classifier can differentiate the reception patterns and perform increasingly better, the further away the spoofed track deviates from the real aircraft track. note that in the worst case, a distance of approx. $\sqrt2$-times the grid resolution can still point to the same cluster. However, increasing the distance further guarantees different clusters.

 그림8은 편차와 경과시간을 원래 트랙에 대한 거리로 합친다. 우리의 평가 프로토타입에서 최대 하나의 그리드 해상도까지의 거리 즉, 10km에 대하여 평균 점수는 빠르게 0.5에 다다른다. 이 지점에 다다른 후에, 감소는 느려지고 두번째 그리드 해상도에 대하여 대략 0.35에 도달한다. 거리가 더 멀어지면 오직 평균 점수가 적당히 감소하고 거의 이 지점에서 안정된다. 우리는 분류기가 수신 패턴들을 분류하고 점점 더 좋게 수행할 수록 실제 항공기 트랙으로부터 위조된 트랙 편차들이 멀어진다는 것을 관찰한다.최악의 경우 그리드 해상도의 약 $\sqrt2$배의 거리가 여전히 동일한 클러스터를 가리킬 수 있다는 점에 유의하라. 그러나 거리를 더 늘리면 서로 다른 클러스터가 보장된다.

 We now approach the question of how we decide aircraft tracks, in contrast to the aforementioned evaluations where we showed average scores over all test runs for individual reports. Figure 7 and 8 show that the score fluctuates and that authentic reports are sometimes labeled as malicious. Even when no attacks are applied, we never reach a perfect score of 1. Hence, the detection of attacks cannot be based on single messages alone without triggering a high number of false alarms. Considering that we designed our system as an augmentation system for attack detection, false alarm events are disruptive and a high number is unacceptable.

 앞서 언급한 각 보고서들에 대한 모든 테스트 실행에 대한 평균 점수를 보여주는 평가들과는 대조적으로, 우리는 어떻게 우리가 항공기 트랙들을 선택했는지에 대한 질문에 접근한다. 그림 7과 8은 점수가 변동하고 실제 보고서들이 때때로 악의적인것으로 라벨링되는 것을 보여준다. 심지어 아무 공격도 적용되지 않을 때에도, 우리는 절대 완벽한 1점에 도달하지 못한다. 더군다나, 공격의 탐지는 많은 수의 잘못 울리는 알람들을 트리거 하는 것 없이 단일 메시지 홀로 기반이 될 수 없다. 우리는 우리의 시스템을 공격 탐지를 위한 추가적인 시스템으로써 설계했다는 점을 고려할 때, 잘못 울리는 알람들은 파괴적이고 많은 수는 받아들일 수 없다.

 To compensate for single false positives, i.e., malicious patterns detected when no attack is applied, we implement time windowing. In particular, we tested three different time windows $w$, i.e., 5 min, 10 min, and 15 min. The time windowing is only applied backwards such that the score at time $t$ becomes the average score of all received reports within the last $w$ minutes. The final decision is then based on score thresholds. With the target of minimizing false alarms, we set the threshold at the lowest score that we observed across all randomly selected 1000 aircraft tracks at any given time after $t_{attack}$. As a result, we achieve a false positive rate of 0% by design with respect to the considered tracks. The selected threshold depends on the length of the time window, where shorter time windows lead to higher thresholds and larger time windows allow tighter thresholds.

 공격이 적용되지 않았을 때 탐지되는 악의적인 패턴들과 같은 단일 오탐을 위해 보완하기 위해서, 우리는 타임 윈도우를 구현한다. 특히, 우리는 세 가지 다른 타임 윈도우($w$)(5분, 10분, 15분)를 테스트했다. 타임 윈도우는 오직 역방향으로 적용되기 때문에, 시간 $t$에서의 점수가 마지막 $w$분동안 안에 모든 수신된 보고서들의 평균 점수가 된다. 그러고 나서 최종 결정은 점수 임계값을 기반으로 한다. 오탐을 최소화하는 것을 목표로, 우리는 임계값을 $t_{attack}$후에 주어진 시간에서의 무작위하게 선택된 모든 1000개의 항공기 트랙들에서 관측한 가장 낮은 점수로 설정한다. 결과적으로, 우리는 고려된 트랙들에 따라서 디자인함으로써 오탐율 0%를 달성했다. 선택된 임계값은 타임 윈도우의 길이에 따라 다르다. 타임 윈도우가 짧으면 임계값이 높아지고, 타임 윈도우가 길어지면 임계값이 줄어든다.

 In Table VII, we list the GPS spoofing detection performance considering different deviations and time windows. We analyzed the attack detection rate, i.e., the number of detected attacks compared to all tested runs and the detection delay, i.e., the time at which we observed the threshold violation and raised an alarm. We additionally state the median and the standard deviation. Bold entries mark the best results in each row. We want to highlight that for every configuration the FPR is 0% due to how the threshold is chosen.

 표 VII에서, 우리는 다양한 편차와 타임 윈도우를 고려하여 GPS spoofing 탐지 성능을 리스트했다. 우리는 공격 탐지율, 즉 테스트된 모든 실행과 비교하여 탐지된 공격들의 수와 탐지 지연, 즉 우리가 임계값 위반을 관측하고 알람을 울리는 시간을 분석했다. 우리는 추가적으로 중앙값과 표준 편차를 명시한다. 두꺼운 글씨는 각 행에서의 가장 좋은 결과를 표시한다. 우리는 임계값이 선택되는 방식으로 인해 모든 구성에서 FPR이 0%인 것을 강조하고자 한다.

 With increasing deviation $\alpha$, the attack detection reaches up to approx. 99.5%. An attack counts as detected when the threshold is undercut within the first hour after the launch of the attack. The missing 0.5% that were not detected are due to very slow or even parking aircraft. The impact of GPS spoofing becomes negligible in such scenarios considering how we simulated it. The rest of the deviated aircraft tracks are detected with a very high probability. The detection delay strongly depends on the applied deviation $\alpha$. For higher values, the average detection delay can go as low as approx. 6 min and standard deviations around 8 min. The time window $w$ also impacts the performance. The implementation of different time windows is beneficial since the best attack detection rate and the detection delay is dependent on the applied deviation $\alpha$.

 증가하는 편차에 따라서, 공격 탐지는 대략 99.5%까지 도달한다. 공격은 공격이 시작된 후의 첫 한 시간 이내에 임계값이 감소하면 탐지된 것으로 간주한다. 탐지되지 않은 0.5%가 누락된 것은 매우 느리거나 주차된 항공기 때문이다. 이러한 시나리오에서는 시뮬레이션 방식을 고려할 때, GPS spoofing의 영향은 무시할 만 하다. 나머지 경로를 벗어난 항공기 트랙들은 매우 높은 확률로 탐지된다. 탐지 지연은 적용된 편차 $\alpha$에 매우 의존한다. 값이 높을수록, 평균 탐지 지연은 약 6분 표준 편차로는 8분 정도로 낮아질 수 있다. 타임 윈도우 $w$는 또한 성능에 영향을 준다. 다양한 타임 윈도우의 구현은 가장 좋은 공격 탐지율과 탐지 지연이 적용된 편차 $\alpha$에 따라 다르기 때문에 유용하다.

 2) ADS-B Spoofing: For the evaluation of the ADS-B spoofing detection performance, we specifically focus on the outcome of the cross check. Since an attacker is able to generate arbitrary reports, we assume that an attacker can successfully remain undetected by the sanity, differential, and dependency check. Considering the testing set for the cross check, we take the same sampled aircraft tracks from the GPS spoofing evaluation but apply ADS-B spoofing according to Section IV. At time $t_{attack}$, the attacker launches the spoofing attack representing a scenario where an aircraft track would normally end, but is continued by fake injections into the system. We distinguish between three scenarios depending on the targeted number of sensors (see Figure 6). Notably, we use a classifier that is trained with samples from normal operation and simulated samples from ADS-B spoofing.

 2) ADS-B Spoofing ADS-B spoofing 탐지 성능의 평가를 위해서, 우리는 특히 상호검증의 결과에 집중한다. 공격자가 임의의 보고서들을 생성할 수 있기 때문에, 우리는 공격자가 성공적으로 온전성, 차별성, 의존성 검사에 탐지되지 않았다고 가정한다. 상호검증을 위한 테스트 세트를 고려해보면, 우리는 동일한 GPS spoofing 평가를 위해 표본화된 항공 트랙을 사용한다. 하지만, 섹션 IV에 서 보듯이 ADS-B spoofing에 적용한다. $t_{attack}$시간에서, 공격자는 항공 트랙이 정상적으로 끝났지만, 시스템에 가짜 주입으로 인해 계속 진행되고 있는 시나리오를 의미하는 spoofing attack를 실행한다. 우리는 타겟이 된 센서들의 수(그림 6 참조)를 통해서 세 가지 시나리오들을 구분한다. 우리는 정상 수행의 표본과 ADS-B spoofing의 시뮬레이션 표본으로 학습된 분류기를 사용한다는 점에 유의해라.

Results. The resulting average scores of all three scenarios are depicted in Figure 9. One can see that the score for normal operation is very close to 1, while any form of ADS-B spoofing drastically reduces the average score across all 1000 runs. This change is almost immediately after the attack has been launched and continues to decrease afterwards. Furthermore, the scenarios impact the scores differently. From an attacker's perspective, injecting reports from multiple but not from all sensors is superior to all other strategies.

결과. 모든 세 시나리오들의 평균 점수의 결과는 그림 9에 묘사되어있다. 어떤 것들은 1000번의 수행 동안에 평균 점수가 급작스럽게 하락하는 반면에, 정상 수행에 대한 점수는 1에 매우 가깝다는 것을 볼 수 있다. 이러한 변화는 거의 공격이 시작된 이후에 즉시 발생하고 점점 감소한다. 게다가, 시나리오들은 점수들에 다른 영향을 준다. 공격자의 관점에서는, 모든 센서들이 아닌 복수개의 센서들에게 가짜 보고서들을 주입하는 것은 다른 모든 전략들보다 우월하다.

 We argue that even an optimized attacker strategy cannot emulate typical reception patterns by only affecting specific sensors. Since sensors are geographically distributed at unknown positions, an attacker cannot systematically control which and how many sensors receive the fake reports. Eventually, an attacker needs to broadcast from a location close to the claimed position to emulate realistic message reception patterns, virtually becoming a legitimate broadcast from the advertised position.

 우리는 최적화된 공격자 전략조차도 오직 영향을 받은 특정 센서들에 의해서 전형적인 수신 패턴들을 에뮬레이트 할 수 없다고 주장한다. 센서들이 알려지지 않은 위치에서 지리적으로 분산되었기 때문에, 공격자는 센서들의 수와 어떤 센서들이 가짜 보고서들을 수신할 지 통제할 수 없다. 결국, 공격자는 실제 메시지 수신 패턴들을 에뮬레이트하기 위해서 타겟 위치에 가까운 장소로부터 방송을 할 필요가 있다. 이는, 알려진 위치로부터 가상의 합법적인 방송이 된다.

 Even when targeting multiple sensors, constantly missing reports from sensors within the reception range is a strong indication for some kind of injection. Naturally, the number of sensors observing the cluster where the injection takes place impacts the significance. The patterns have less variations when fewer sensors are operated and the differences to malicious patterns will be less obvious. Figure 10 shows the average score in relation to the number of observing sensors. Having only three sensors, the attacker can remain undetected in more cases than in clusters with a sensor coverage of 10, 30, or 50.

 심지어 복수 개의 센서들을 표적으로 할 때에도, 수신 범위 내에 센서들로부터 끊임없이 보고서들이 손실되는 것은 몇 가지 종류의 주입 공격에 대한 강한 암시이다. 자연스럽게, 주입 공격이 발생하는 클러스터를 관측하고 있는 센서들의 수는 중요도에 영향을 준다. 패턴들은 적은 수의 센서들이 수행되어질 때 더 적은 변동성을 가지고 악의적인 패턴들에 대한 차이점은 덜 명백해진다. 그림 10은 관측 센서들의 수에 대한 관계에 대한 평균 점수를 보여준다. 오직 3개의 센서들을 가지는 것은 공격자가 센서 커버리지가 10, 30, 50인 클러스터내에서 보다 더 많은 경우에서 탐지되지 않을 수 있다.

 3) Sensor Control/Sybil Attack: To evaluate our detection performance of sensor control/Sybil attacks, we again focus on the outcome of the cross check. We consider two scenarios with different numbers of compromised sensors, i.e., a single sensor or equality between the attacker's sensors and the number of sensors already observing that specific airspace. Notably, the attackers' sensors initially participate normally and are already considered when message reception patterns are trained. After $t_{attack}$, the attacker starts to use the controlled sensors to inject an aircraft track. Compared to our assumptions for ADS-B spoofing, the attacker is now capable of emulating arbitrary reception patterns using all the controlled sensors while benign sensors within the same cluster remain unaffected.

 3) Sensor Control/Sybil Attack Sensor Control/Sybil Attack의 탐지 성능을 평가하기 위해서, 우리는 다시 상호 검증의 결과에 집중한다. 우리는 오염된 센서들의 수가 다른 2가지 시나리오들, 즉 단일 센서 또는 공격자의 센서들과 특정 공역을 이미 관측하는 센서들의 수 간의 일치를 고려한다. 공격자의 센서들이 초기에 정상적으로 참여하고 메시지 수신 패턴들이 학습되어졌을 때, 이미 고려되어진다는 것에 유의해라. $t_{attack}$이후에, 공격자는 항공 트랙을 주입하기 위해서 통제된 센서들을 사용하기 시작한다. ADS-B spoofing을 위한 우리의 가정들을 비교하여 공격자가 동일한 클러스터내에 있는 정상 센서들이 영향을 받지 않은채로 유지되는 동안에, 모든 통제된 센서들을 사용하면서 임의의 수신 패턴들을 모방할 수 있다.

Results. The results are very similar to the ADS-B spoofing results. The impact on the score is immediate and can be clearly distinguished from normal behavior. The reasoning behind the similar results are based on the benign sensors that are unaffected by the attacker. A message injection from the controlled sensors represents the very unlikely case of a high number of benign sensors missing on the same message. The detection of Sybil attacks is hence based on missing reports rather than all sensors agreeing on the same message. Figure 10 can be converted to this scenario when considering the sensor coverage of only the uncompromised sensors.

결과. 결과들은 ADS-B spoofing 결과와 매우 유사하다. 점수에 대한 영향은 즉각적이고 정상 수행과 명확하게 구분될 수 있다. 비슷한 결과의 이유는 공격자에 의해 영향을 받지 않는 정상 센서들때문이다. 통제된 센서들로부터 메시지 주입은 동일한 메시지에 많은 수의 정상 센서가 누락된 가능성이 매우 낮다는 것을 나타낸다. 그림 10은 오직 손상되지 않은 센서들의 센서 커버리지만을 고려할 때, 이러한 시나리오로 변환될 수 있다.

 Nevertheless, some limitations need to be highlighted. If the attacker controls every sensor for one cluster, arbitrary patterns can be emulated and we have no chance of detecting the attack. However, as soon as the attacker tries to inject reports for clusters that are already observed by sensors, the attack can be detected. The vast majority of airspace is already observed by at least one sensor (see Table IX). We argue that as long as the majority of benign sensors operate normally, the attack can still be detected.

 그럼에도 불구하고, 약간의 제약들은 강조될 필요가 있다. 만약, 공격자가 한 클러스터에 대해서 모든 센서를 통제한다면, 임의의 패턴들은 에뮬레이트 될 수 있고 우리는 공격을 탐지할 기회가 없다. 하지만, 공격자가 이미 센서들에 의해 관측되고 있는 클러스터들에 대하여 보고서들을 주입하려 한다면, 공격은 탐지될 수 있다. 공역의 대부분은 이미 최소 하나의 센서들에 의해서 관측되고 있다(표 IX 참고). 우리는 정상 센서들이 가능한 오래동안 정상적으로 수행되고 있는 한, 공격은 여전히 탐지 될 수 있다고 주장한다.

 4) Combined Attacks: Thus far, we have evaluated the detection performance of individual attacks, i.e., GPS spoofing, ADS-B spoofing, and sensor control/Sybil attacks. We now analyze if any attack combination can increase the attacker's chance of remaining undetected. Notably, sensor control is superior to ADS-B spoofing since a fully compromised sensor cannot only inject any form of false ADS-B reports (as it is the case for ADS-B spoofing) but also drop any other messages the sensor may receive. Hence, ADS-B spoofing can be considered a subset of the sensor control/Sybil attack class. The success of their combination can be upper bounded by the success an attacker would have who instead also controls the sensors affected by ADS-B spoofing. While an attacker controlling a subset of sensors may still decide to additionally spoof other sensors, the detection performance is closely tied to the number of benign sensors.

 4) Combined Attacks 지금까지, 우리는 각각의 공격들, 즉 GPS spoofing, ADS-B spoofing, and sensor control/Sybil attack에 대한 탐지 성능을 평가해왔다. 우리는 이제 어떤 공격 조합이라도 탐지되지 않은 채로 유지될 공격자의 기회를 증가시킬 수 있는지 분석한다. 센서 통제는 완전히 손상된 센서들이 ADS-B 보고서들을(ADS-B spoofing의 경우처럼) 주입할 수 있을 뿐 아니라, 센서가 수신할 지도 모르는 다른 모든 메시지들을 차단 시킬 수 있기 때문에 ADS-B spoofing보다 우월하다는 점에 유의하라. 따라서 ADS-B spoofing은 sensor control/Sybil attack 클래스의 하위 집단으로 고려될 수 있다. 공격 조합의 성공은 ADS-B spoofing에 영향을 받은 센서들을 통제하는 공격자의 성공에 따라 상한이 정해질 수 있다. 센서들의 하위 집합을 통제하는 공격자가 추가적으로 다른 센서들을 속이기로 결정할지도 모르는 반면에, 탐지 성능은 정상 센서들의 수에 매우 밀접하게 연관되어 있다.

 We focus on reports affected by GPS spoofing and ADS-B spoofing at the same time, i.e., a fake GPS track that is injected via ADS-B spoofing. We set the deviation $\alpha$ to 5$\degree$ and assume an attacker to inject the track via spoofing multiple sensors. We consider the impact on the detection performance from two different directions. Figure 11 shows the change based on a classifier that is indicative for GPS spoofing. Figure 12 depicts the other perspective, where the ADS-B spoofing classifier evaluates the attack combination.

 우리는 동시에 GPS spoofing과 ADS-B spoofing에 영향(ADS-B spoofing을 통해서 주입된 가짜 GPS 트랙)을 받은 보고서들에 집중한다. 우리는 편차 $\alpha$를 5$\degree$에 맞추고 복수의 센서들을 spoofing함으로써 트랙을 주입하는 공격자를 가정한다. 우리는 두 가지 다른 방향으로 탐지 성능에 대한 영향을 고려한다. 그림 11은 GPS spoofing을 나타내는 분류기를 기반한 변화를 보여준다. 그림 12는 다른 관점, ADS-B spoofing 분류기가 공격 조합을 평가하는 것을 보여준다.

Results. Comparing the detection performance of fake GPS spoofing reports to additional ADS-B spoofing, one can clearly notice the sudden drop in score due to the ADS-B spoofing in the combination. Over the cause of 30 min, the average score is constantly lower rendering the combination unfavorable for the attacker. Surprisingly, from the perspective of ADS-B spoofing, we can notice that the attack combination actually results in slightly higher scores and that the effect increases over time. It seems that a combination favors the attacker, however, the score differences are due to a chance that is not reflected in the figure: By additionally manipulating the GPS positions, the fake track faster approaches edge areas that are observed by less sensors and hence the classification looses significance (compare Figure 10). As long as enough benign sensors are unaffected, any attack combination does not favor the attacker.

결과 가짜 GPS spoofing 보고서들의 탐지 성능과 추가적인 ADS-B spoofing을 비교하면, 조합에서의 ADS-B spoofing 때문에 급격하게 점수가 감소하는 것을 명백하게 알 수 있다. 30분 동안 평균 점수는 일정하게 낮아져 공격자에게 불리하게 작용한다. 놀랍게도, ADS-B spoofing의 관점으로부터, 우리는 공격 조합이 실제로 약간 더 높은 점수를 초래한다는 점과 시간이 흐름에 따라 효과가 상승한다는 점을 알 수 있다. 공격을 조합하는 것이 공격자에게 더 유리한 것처럼 보인다. 하지만, 점수 차이는 그림에 반영되지 않은 기회: 추가적인 GPS 위치의 조작을 함으로써, 가짜 트랙이 적은 센서들에 의해서 관찰되고 있는 가장자리 지역들에 빠르게 접근하고 그로 인해 (그림 10과 비교하여)분류의 중요도를 잃기 때문이다. 정상 센서들이 영향을 받지 않는 한, 어떠한 공격 조합도 공격자에게 유리하지 않다.

 5) From Single Reports to Moving Tracks: In our evaluation, we linked the classification results of individual reports to make a decision for an entire aircraft track. While single reports may be falsely classified as malicious, time windowing mitigates this effect. The trained models for different clusters are separated and some may be more concise than others. A fact that facilitates our detection scheme is the intrinsic movement of aircraft such that a track traverses many different clusters over its course. As a result, the combined decisions of multiple clusters benefits from clusters with higher sensor coverage, eventually yielding a very high classification performance even when clusters are involved that are hard to decide.

 5) From Single Reports to Moving Tracks: 우리의 평가에서, 우리는 전체 항공 트랙을 결정하기 위해서 각 보고서들의 분류 결과들을 연결시켰다. 단일 보고서들이 악의적인 것으로 잘못 분류될지도 모르지만, 타임 윈도우를 사용하는 것은 이러한 효과를 완화시킨다. 다른 클러스터들을 위한 훈련된 모델들은 분리되어지고 일부는 다른것들 보다 더욱 간결할 지도 모른다. 우리의 탐지 체계를 용이하게하는 사실은 트랙이 그것의 경로를 통해서 여러 다른 클러스터들을 횡단하도록 항공기가 본질적으로 움직인다는 것이다. 그 결과, 복수의 클러스터들의 조합된 결정은 더 높은 센서 커버리지를 가지는 클러스터의 이점을 가지며, 결국 결정하기 어려운 클러스터가 포함되어 있어도 매우 높은 분류 성능을 가진다.

2. Attack Analysis: Type of Attack

 So far, we have used a different classifier for each considered attack vector. The type of attack can be trivially determined by the classifier that indicated the attack. We neglected the possibility that classifiers, e.g., tailored towards GPS spoofing detection, may also raise an alarm when faced with ADS-B spoofing, and vice versa. Note that, when no attack is applied no classifier will yield any false alarm due to the way we set our thresholds. We now analyze whether we can tell attack patterns apart. In order to evaluate the ability to differentiate between our simulated attacks, we transform the binary classification into a multiclass classification that decides the type of attack. We trained a DT classifier with reports from GPS spoofing and ADS-B spoofing. Since both attacks have multiple configurations, we chose a deviation of 20$\degree$ for GPS spoofing and multiple sensors affected for ADS-B spoofing. We apply a time windowing of $w = 15$min and evaluate the result at $t_{attack}$ + 30min. Figure 13 depicts the confusion matrix of the classification results.

 지금 까지, 우리는 각 고려된 공격 벡터에 대하여 다른 분류기를 사용했다. 공격의 유형은 공격을 나타내는 분류기에 의해 결정될 수 있다. 우리는 GPS spoofing 탐지를 위해 딱 맞추어진 분류기들이 ADS-B spoofing을 마주했을 때, 알람을 울릴 수 있고 그 반대의 경우도 발생할 수 있다는 가능성을 무시했다. 공격이 적용되지 않으면, 임계값을 설정하는 방법 때문에 잘못된 알람이 울리지 않는다는 것을 주의하라. 이제 공격 패턴을 구분할 수 있는지 분석한다. 우리의 시뮬레이션된 공격들을 구분하는 능력을 평가하기 위해서, 우리는 이진 분류를 공격 유형을 결정하는 다중 클래스 분류기로 변환한다. 우리는 GPS spoofing과 ADS-B spoofing의 보고서를 통해 DT 분류기를 훈련했다. 두 공격 모두 다양한 구성을 가지고 있으므로, 우리는 GPS spoofing을 위해서는 20$\degree$의 편차를, ADS-B spoofing을 위해서는 영향을 받는 여러개의 센서들을 선택한다. $w = 15$분의 타임 윈도우를 적용하고 그 결과를 $t_{attack}$ + 30min으로 평가한다. 그림 13은 분류 결과들의 혼동 행렬을 보여준다.

Results. Considering aircraft tracks without any attack modification applied, the combined classifier yields no false classifications. For GPS spoofing with $\alpha = 20\degree$, 78.5% of the randomized runs are detected and correctly identified, while 13.9% are still considered normal. Approx. 7.6% of the cases are assigned as ADS-B spoofing. In comparison, 85.4% of ADS-B spoofing tracks are classified correctly, 4.2% are decided to be normal, and 10.4% are mixed with GPS spoofing. Our classifier struggles with this separation due to the similar impact on reception patterns in the early phases of GPS spoofing. All in all, the majority of attacks were correctly assigned and separated.

결과. 어떠한 공격 수정이 적용되지 않은 항공기 트랙을 고려할 때, 결합된 분류기들은 잘못된 분류를 하지 않는다. $\alpha = 20\degree$를 가지는 GPS spoofing의 경우 무작의 실행의 78.5%가 탐지되고 올바르게 확인된 반면에 13.9%는 여전히 정상으로 고려된다. 약 7.6%의 경우는 ADS-B spoofing에 할당된다(오탐). 이와 비교해서, ADS-B spoofing의 85.4%는 올바르게 분류되고 4.2%는 오탐, 10.4%는 GPS spoofing과 합쳐진다. 우리의 분류기는 GPS spoofing의 초기 단계에서 수신 패턴에 미치는 비슷한 영향으로 인해 이러한 분리에 어려움을 겪고 있다. 전체적으로, 공격의 대부분은 정확하게 할당되고 분리된다.

3. Attack Analysis: Affected Sensors

 We generally differentiate between sensors that fell victim to an attack themselves and sensors that are actively collaborating. For instance, in a GPS or ADS-B spoofing attack, sensors may be faced with bogus input data, however, they are still functioning correctly and are otherwise conform with their intended behavior. While for GPS spoofing attacks the reception patterns reflect normal behavior--but for a different message origin as claimed, the reception patterns for ADS-B spoofing attacks are altered. When our attack analysis reveals the type of attack being of the latter case, the reporting sensors may be disconnected from the network and excluded from the cross checking procedure of other reports. These sensors are directly affected by the attack and their recordings cannot be trusted. However, once the attack is concluded, the identified sensors may be reactivated to again contribute to the network.

 우리는 일반적으로 공격의 희생양이 된 센서들과 적극적으로 협동을 하고 있는 센서들을 구분한다. 예를 들어서, GPS 또는 ADS-B spoofing attack에서 센서들은 가짜 입력 데이터를 직면할 수 있다. 하지만, 센서들은 여전히 올바르게 기능하고 그들이 의도한대로 행동하지 않는다. GPS spoofing attacks을 위한 수신 패턴들은 정상 행동을 반영하는 반면에, 주장한 바와 같이 다른 메시지 발신지의 경우, ADS-B spoofing attacks을 위한 수신 패턴들은 수정된다. 우리의 공격 분석이 후자의 공격 유형을 드러낼 경우, 보고하는 센서들은 네트워크로부터 연결 해지되고 다른 보고서들의 상호 검증 절차로부터 배제된다. 이러한 센서들은 직접적으로 공격에 의해 영향을 받고 그들의 기록들은 신뢰될 수 없다. 하지만, 공격이 끝난다면, 신원이 확인 된 센서들은 네트워크에 기여하기 위해 재활성화 된다.

 On the other hand, if the attack analysis reveals a sensor control/Sybil attack, we are faced with compromised sensors actively launching attacks on the network. All sensors that reported the reception of identified fake reports need to be considered as part of an attacker-controlled sensor union. Any shared reports from such sensors cannot be considered trustworthy. Their participation in the crowdsourcing network must be shut down and their forwarded reports filtered out accordingly to recover the integrity of the network.

 반면에, 공격 분석이 sensor control/Sybil attack으로 드러난다면, 우리는 네트워크에서 공격을 수행하고 있는 손상된 센서들을 마주할 수 있다. 식별된 가짜 보고서를 수신했다고 보고하는 모든 센서들은 공격자-통제하의 센서 결합의 한 부분으로써 고려될 필요가 있다. 이러한 센서들로부터 공유된 어떠한 보고서들이라도 신뢰적이라고 고려될 수 없다. 네트워크의 무결성을 복구하기 위해서 크라우드소싱 네트워크의 그들의 참여는 종료되여야만 하고 그들의 다음 보고서들은 필터링 된다.

4. Impact of Grid Resolution

 The resolution of our considered underlying grid determines the process of assigning reports and sensors to cluster $C_j$. The higher the grid resolution, the finer is the differentiation between regions and eventually their reception patterns. However, increasing the grid resolution not only increases the computational load but can also lead to overfitting areas to the monitoring sensors. For instance, since we do not know the exact locations of sensors, we need to learn the observed area from reported ADS-B messages. The chances that a sensor did not report any message from a specific area increase with smaller sizes even though the sensor actually observes that airspace. While we chose a grid size with edge lengths of 10km to compare the attack detection performance, we also evaluated the impact of different grid resolutions and gained the following insights.

 고려된 그리드의 해상도는 클러스터 $C_j$에 보고서와 센서들을 할당하는 프로세스를 고려한다. 그리드 해상도가 높을수록, 지역간의 차별화와 결국 그들의 수신 패턴이 미세해진다. 하지만, 그리드 해상도를 올리는 것은 계산 부하를 증가시킬 뿐 아니라, 관측 센서들에 영역이 과적합될 수 있다. 예를 들어서, 우리는 센서들의 정확한 위치를 모르기 때문에, 보고된 ADS-B 메시지들로부터 관측된 영역을 학습할 필요가 있다. 센서가 실제로 해당 공역을 관측하고있다 할지라도 특정 영역으로부터 어떠한 메시지도 보고하지 않을 가능성은 크기가 작을수록 증가된다. 우리가 공격 탐지 성능을 비교하기 위해서 10km의 가장자리를 가지는 그리드 크기를 선택했지만, 우리는 또한 다양한 그리드 해상도의 영향을 평가하고 다음과 같은 인사이트를 얻었다.

Results. The greater the proliferation of a cluster is, the more sensors are potentially observing at least parts of the area. As a consequence, the reception patterns feature more active sensors and have a higher variance within the same cluster. However, this also makes it harder to have a clear distinction between normal operation and malicious patterns. On the other hand, clusters with very tight areas actually prevent the estimation of meaningful reception patterns and thus also decrease the validity. Since the attack detection performance is related to the differences in the reception patterns, we determined a reasonable trade-off between sensitivity and generalization, which resulted in the grid resolution of 10km.

결과. 클러스터의 확산이 클수록, 더 많은 센서들이 잠재적으로 영역의 적어도 일부분들을 관측하고 있다. 그 결과, 수신 패턴들은 더 많은 활성 센서들을 특징으로 하고 동일 클러스터 내에서 더 많은 분산을 가진다. 하지만, 이것은 또한 정상 수행과 악의적인 패턴간의 명백한 구분을 어렵게 만든다. 반면에, 매우 좁은 영역의 클러스터들은 실제로 의미있는 수신 패턴들의 추정을 방해하므로 유효성을 감소시킨다. 공격 탐지 성능이 수신 패턴들의 차이와 관련이 있기 때문에, 우리는 민감도와 일반화 사이에서 합리적인 절충점을 결정하여 10km 그리드 해상도를 얻었다.

5. Time Dependency

 To evaluate the time dependency of our detection scheme, we additionally assess its performance on a dataset gathered for February 17, 2020. This dataset represents a normal weekday, two days after the previously analyzed day. This day was chosen due to a temperature drop and rainy weather and thus represents unfavorable conditions. The number and paths of flights on this new day is similar (but not identical) to the previously selected dataset. During this day, the OpenSky Network recorded over 135 million ADS-B reports and 728 active sensors. The structure of the sensor network on both days is strongly overlapping showing very minor fluctuations. The evaluations steps are kept the same to our previous analysis, revealing the following results.

 우리의 탐지 체계의 시간 의존성을 평가하기 위해서, 우리는 추가적으로 2020년 2월 17일에 모았던 데이터세트에 대한 성능을 추가로 평가한다. 이 데이터 세트는 이전에 분석된 날로부터 2일 후의 정상적인 평일을 나타낸다. 이 날은 기온이 낮아지고 비가 오는 날씨로 인해 선택되었으며 불리한 조건을 나타낸다. 이 날의 항공기의 수와 경로들은 이전의 선택된 데이터세트들과 비슷하다(동일하진 않음). 이 날 동안 OpenSky Network는 1억 3,500만개의 ADS-B 보고서와 728개의 활성 센서들을 기록했다. 두 날의 센서 네트워크의 구조는 매우 적은 변동을 보이며 중복되어 있다. 평가 단계는 이전의 분석과 동일하게 유지되었으며 다음과 같은 결과가 나왔다.

Results. Overall, the results show very little deviations from the previous results and the extent of variation is comparable to the homogeneity of the sensor network. In particular, we present results showing the detection performance considering GPS spoofing attacks in Table VIII. The results for both ADS-B spoofing and sensor control/Sybil attacks are overlapping with the prior results such that differences cannot be captured visually, hence we abstain from presenting identical figures. All in all, this provides evidence which suggests that $(i)$ different flight paths, $(ii)$ varying airspace density, and $(iii)$ changing weather conditions only slightly influence the detection performance of our scheme, indicating its robustness against these parameters.

결과. 전체적으로, 결과들은 이전의 결과들로부터 매우 적은 편차를 보여주고 변화의 정도는 센서 네트워크의 동질성과 비슷하다. 특히, 표 VIII에서 GPS spoofing attacks을 고려한 탐지 성능을 보여주는 결과를 제시한다. ADS-B spoofing과 sensor control/Sybil attacks에 대한 결과는 이전 결과와 중복되어 차이를 시작적으로 포착할 수 없으므로, 동일한 수치를 제시하지 않는다. 결국, 이는 $(i)$다른 비행 경로, $(ii)$공역 밀도 변화, $(iii)$날씨 조건 변화가 우리 체계의 탐지 성능에 약간의 영향만을 미쳐 이러한 매개변수들에 대하여 견고하다는 것을 보여주는 증거를 제시한다.

6. Computational Performance

 The implementation of the ML-based cross check imposed the challenge of handling more than 132 million reports from more than 700 sensors, just for a single day and only in Europe. With this massive amount of data, training on the entire dataset became infeasible on off-the-shelf equipment. To bring down the required time for training and classification, we decided to split the data into grids, where the data in each grid can be processed separately. Moreover, the training duration is a one-time cost and was well doable on standard hardware. If implemented on a designated server, the required time is expected to be lowered by magnitudes. As a result, even retraining on a regular basis becomes possible. The recurring costs of classifications, on the other hand, are only a minor fraction of the training duration such that all classification for an entire day only took a few minutes and can thus be performed efficiently in real-time.

 ML 기반의 상호 검증의 구현은 단지 유럽에서의 하루 동안 700개 이상의 센서들로부터 1억 3,200만개 이상의 보고서들을 다뤄야하는 문제를 제시한다. 이러한 거대한 양의 데이터를 가지고, 전체 데이터세트에 대한 학습은 시중에 나와있는 제품 사용을 불가능하게 만든다. 학습과 분류에 걸리는 요구되는 시간을 줄이기 위해서, 우리는 각 그리드안에 있는 데이터가 각각 처리될 수 있도록 데이터를 그리드로 분리했다. 게다가, 학습 기간은 일회성 비용이며 표준 하드웨어에서도 잘 수행할 수 있었다. 지정된 서버에서 구현되면, 요구 시간은 크기만큼 낮아질 것으로 예상된다. 그 결과, 정기적으로 재교육하는 것이 가능해졌다. 반면에, 분류의 반복되는 비용은 오직 교육기간의 극히 일부에 불과하기 때문에 하루종일 모든 분류를 몇 분 밖에 걸리지 않으므로 실시간으로 효율적으로 수행할 수 있다.

Discussion

 We discuss important properties of our developed system: $(i)$ implicit trust in the data source, $(ii)$ limitations, $(iii)$ attacker's knowledge, $(iv)$ false alarm events, $(v)$ the current attack resilience, $(vi)$ optimized sensor deployment, and $(vii)$ further extensions.

 우리는 우리의 발전 시스템의 중요한 성질에 대해서 얘기한다. $(i)$데이터 원천의 절대적 신뢰, $(ii)$제한, $(iii)$공격자의 지식, $(iv)$ 거짓 알람 이벤트, $(v)$ 현재 공격 회복력, $(vi)$최적화된 센서 배포, 그리고 $(vii)$추가 확장들.

1. Implicit Data Source Trust

 We base the evaluation of our trust system on data provided by the OpenSky Network, which records real-world air-traffic reports. However, we take the data "as is" and consider it to represent normal behavior. We cannot exclude the existence of erroneous data or even reports that resulted from some kind of attack. Nevertheless, we throughly analyzed the reports of our selected day (February 15, 2020) without any findings. While our system is designed to analyze live data, it can also be used to find unusual events and potential attacks in the recorded air-traffic reports in a retrospective view.

 우리는 실제 항공 교통 보고서들을 기록하는 the OpenSky Network에 의해 제공되는 데이터에 대한 우리의 신뢰 시스템의 평가들을 기반으로 한다. 하지만, 우리는 데이터를 "있는 그대로" 사용하고 그 데이터들이 정상 행동을 나타낸다고 고려한다. 우리는 몇 가지의 공격으로부터 비롯되는 많은 양의 데이터나 보고서들의 존재를 배제할 수 없다. 그럼에도 불구하고, 우리는 어떠한 발견도 없이 우리가 선택한 (February 15, 2020)날짜의 보고서들을 분석한다. 우리의 시스템이 실제 데이터를 분석하기위해서 설계되었지만, 회고적 관점에서 기록된 항공 교통 보고서들에 있는 일반적이지 않은 이벤트와 잠재적 공격들을 찾아내는데에 사용될 수 있다.

2. Limitations

 While we state that our system can detect all considered attacks (i.e., GPS spoofing, ADS-B spoofing, and sensor control/Sybil attack), our system is subject to limitations. Independent of the attack, any verification can only be applied in covered airspaces (see Figure 3) which excludes, e.g., the open sea. For the cross check, we further require at least three sensors to yield meaningful results. Given these requirements, we achieved detection delays on the order of minutes, which is a limiting factor in situations where fast reactions are required. We tuned our system towards minimal false alarm events requiring us to delay decision. Allowing the existence of false alarms can significantly lower this delay.

 우리의 시스템이 모든 고려되는 공격들(GPS spoofing, ADS-B spoofing, and sesor control/Sybil attack)을 모두 탐지할 수 있다고 말했던 반면에, 우리의 시스템은 제한이 있는것 같다. 공격과 무관하게, 어떠한 검증도 망망대해를 제외한 커버되는 공역에만 적용된다. 상호 검증을 위해서, 의미있는 결과를 얻기 위해서 최소 3개의 센서들이 더 필요하다. 이러한 요구들을 고려할 때, 빠른 대응이 필요한 상황에서 제한 요소인 탐지 지연을 분 단위로 달성했다. 우리는 결정을 지연시켜야 하는 최소한의 잘못된 경보 이벤트를 위해 시스템을 조정했다. 거짓 경보의 존재를 허락하는 것은 상당히 이러한 연기를 낮춘다.

 Some limitations are specific to the types of attacks as we explain as follows:

 몇 가지 제약들은 우리가 다음에 설명할 몇 가지 종류의 공격들에 대하여 구체적이다:

 1) GPS Spoofing: The limitations of GPS spoofing detection are based on the extent of applied deviation and the grid resolution. With finer grid resolution, the more subtle deviations can be detected. However, the resolution can only be increased to a certain degree. Based on our simulations, a resolution of 10km was identified as a good choice. Fixing the grid resolution to 10km, we consider our system to reliably detect more than 96% of GPS spoofing attacks with a deviation of at least 5$\degree$. Less deviation can only be detected with lower probability or after significantly more time.

GPS spoofing의 한계점은 적용된 편차와 그리드 해상도의 확장을 기반으로 한다. 더 선명한 그리드 해상도는 더 좋은 편차를 찾을 수 있게 한다. 하지만, 해상도는 오직 특정 각도에서만 증가할 수 있다. 우리의 시뮬레이션을 기반으로, 10km의 해상도는 좋은 선택인것 처럼 확인되었다. 10km로 그리드 해상도를 고정하면서, 우리는 우리의 시스템이 최소 5$\degree$의 편차를 가지고 GPS spoofing attack의 96% 이상을 탐지한다고 고려한다. 더 적은 편차는 오직 낮은 확률 또는 상당히 오랜 시간 이후에 탐지될 수 있다.

 2) ADS-B Spoofing: When facing an ADS-B spoofing attack, the detection capability of our system requires the positions of sensors to remain concealed such that an attacker cannot selectively target individual sensors with, e.g., multiple antennas. If an attacker can pinpoint sensors to emulate realistic reception patterns, our system would not be able to detect malicious injections.

ADS-B spoofing attack을 마주할 때, 우리 시스템의 탐지능력은 공격자가 다수의 안테나들과 같은 개별적인 센서들과 함께 선택적으로 목표할 수 없는 숨겨진 채로 남아있는 센서들의 위치를 요구한다. 공격자는 실제와 같은 수신 패턴을 에뮬레이트하기 위해서 센서들의 위치를 정확히 집어낼 수 있다면, 우리의 시스템은 악의적인 주입을 탐지할 수 없을 것이다.

 3) Sensor Control/Sybil Attack: Naturally, an attacker controlling every sensor could overcome any verification scheme due to full control over reported data. Our detection system relies on the existence of benign sensors. In an area with active malicious sensors, we require at least three benign sensors to be able to detect the attack. Notably, we do not consider any form of identity spoofing, in which reports are injected with sensor identities without any control over the indicated sensors. This must be prevented on other layers.

당연하게도, 모든 센서를 제어하는 공격자는 보고된 데이터에 대한 완전한 통제 덕분에 어떠한 검증 체계라도 이겨낼 수 있다. 우리의 탐지 시스템은 정상 센서들의 존재에 의지한다. 활동적인 악의적인 센서들을 가지는 영역에 있어서, 우리는 공격을 탐지하기 위해서 최소 3개의 정상 센서들을 요구한다. 특히, 표시된 센서를 제어하지 않고도 센서 ID로 보고서를 주입하는 어떠한 형태의 신원 스푸핑도 고려하지 않습니다. 이것은 다른 계층에서 보호되어져야만 한다.

 In circumstances that stay within these limiations, our detection scheme achieves the stated performance figures. Outside the limitations, the performance may be heavily degraded. Fortunately, areas where the number of sensors is a limitation are constantly shrinking due to increasing sensor coverage (see Section VI-E).

이러한 제한점들을 가지는 환경에서, 우리의 탐지 체계는 명시된 성능 수치를 달성한다. 제한의 밖에서는, 성능은 매우 낮아질 것이다. 운이 좋게도, 센서들의 수가 제한된 영역들은 센서 커버리지의 증가 덕분에 일정하게 수축한다. (VI-E 참고).

3. Attacker's Knowledge

 In our performance analysis of detecting ADS-B spoofing and Sybil attacks, we considered attackers controlling a certain number of sensors. An attacker with full awareness of our system might try to optimize the pursued attack strategy and imitate authentic reception patterns. For both ADS-B spoofing and Sybil attacks, this can only be achieved to a certain degree and we argue that an attacker cannot overcome the detection scheme in regions with enough sensor redundancy. Even a fully aware attacker does not know the exact locations of other sensors, and hence it is not possible to manipulate them in a targeted manner (e.g., through ADS-B spoofing). Moreover, an attacker cannot access the unprocessed readings of ohter sensors in an effort to localize them. In the case of ADS-B spoofing, where an attacker affects multiple sensors, the actual victims cannot be targeted separately. In the case of a Sybil attack, the attacker could try to emulate realistic reception patterns using the controlled sensors, but cannot do so with the sound user-operated sensors. The better a cluster is covered by benign sensors, the more conspicuous an attack will be. We, therefore, argue that even an attacker, fully aware of our system, cannot overcome the detection scheme due to the concealed locations of other sensors.

ADS-B spoofing과 Sybil attacks을 탐지하는 우리 성능 분석에 있어서, 우리는 특정 수의 센서들을 통제하는 공격자를 고려한다. 공격자는 우리 시스템을 완전히 알아차리고 추구하는 공격 전략을 최적화하기 위해서 노력하고 실제 수신 패턴을 모방하려고 노력할지도 모른다. ADS-B spoofing과 Sybil attacks 모두, 오직 어느 정도만 달성될 수 있고, 우리는 센서 중복이 충분한 지역에서는 공격자가 탐지 체계를 극복할 수 없다고 주장한다. 심지어 완전한 알아차림에도 불구하고 공격자는 다른 센서들의 정확한 위치를 모르기 때문에 목표된 방법(ADS-B spoofing)으로 센서를 조작할 수 없다. 게다가 공격자는 다른 센서들의 처리되지 않은 판독값에 접근하여 위치를 파악할 수 없다. 공격자가 다수의 센서들에 영향을 주는 ADS-B spoofing의 경우에서, 실제 피해자들은 별도로 표적화 할 수 없다. Sybil attack의 경우에서, 공격자는 통제된 센서들을 사용하여 실제와 같은 수신 패턴들들을 에뮬레이트하려고 노력할 수 있지만, 사운드 사용자가 동작하는 센서에서는 그렇게 할 수 없다. 클러스터가 정상 센서들에 의해 더 잘 커버될 수록, 공격은 더 잘 눈에 띄게 된다. 그러므로 심지어 우리 시스템의 완전한 인식을 한 공격자도 다른 센서들의 숨겨진 위치 덕분에 탐지 체계를 극복 할 수 없다고 주장한다.

4. False Alarm Events

 We acknowledge that any false alarm event, i.e., a falsely detected attack, greatly hinders the acceptance of our developed system. Especially when considering safety-related air-traffic surveillance, false alarm events would distract air-traffic controllers leading to the opposite of what we wanted to achieve. With our choice of setting thresholds, we obtained 0% false positives over a dataset of 1000 randomly sampled tracks. Admittedly, this does not guarantee the absent of false alarms. However, our system can be tuned with updated thresholds and time windows if false alarms arises. Even for broader thresholds, we expect meaningful attack detection rates within reasonable delays.

우리는 거짓 경보 이벤트, 즉 잘못된 탐지 공격이 개발된 시스템의 수용을 크게 방해한다는 점을 인정한다. 특히 안전과 관련된 항공 교통 관제를 고려할 때, 거짓 경보 이벤트는 항공 교통 관제사의 주위를 분산시켜서 우리가 달성하고자 하는 것과 반대로 이어질 수 있다. 임계값을 설정하기로 결정하여 무작위로 샘플링된 1000개의 트랙 데이터 세트에서 0%의 오탐률을 얻었다. 물론 그렇다고 해서 거짓 알람이 없다는 것을 보장하지는 않는다. 하지만, 우리의 시스템은 거짓 경보가 발생한다면, 임계값과 타임 윈도우를 업데이트 함으로써 조정할 수 있다. 더 넓은 임계값에서도 합리적인 지연내에서 의미있는 공격 탐지율을 기대할 수 있다.

5. Current Attack Resilience

 The crowdsourcing sensors are at the core of our trust system and their distribution and density are of utter importance for the detection of attacks. The validity of the cross check, i.e., wireless witnessing, increases with the number of sensors covering the same air segments. Thus, the more redundancy, the more variations exist in the reception patterns and the better malicious attacks and sensors can be detected. We analyzed the current resilience of the OpenSky Network by considering regions related to different coverages. Table IX states the breakdown of the total covered area and relates it to the total surface of the European continent.

 크라우드 소싱 센서들은 우리의 신뢰 시스템의 핵심이고 공격 탐지에 대하여 센서들의 분포와 밀도는 매우 중요하다. 동일한 공역 세그먼트를 커버하는 센서들의 수가 증가함에 따라 상호 검증, 즉 무선 목격의 유효성이 증가한다. 그러므로, 중복성이 높을 수록, 수신패턴에서의 더 많은 변화가 존재하고 악의적인 공격들과 센서들을 더 잘 탐지할 수 있다. 우리는 다양한 커버리지들과 관련된 지역을 고려함으로써 the OpenSky Network의 현재 복원력을 분석했다. 표 IX는 커버되는 영역 전체의 고장을 설명하며 유럽 대륙의 전체 표면과 관련있다.

6. Optimizing Sensor Deployment

 To further develop the security of the network, we encourage the deployment of new sensors in less covered areas to optimize the current geographical distribution by optimized network expansion. Based on the coverage information of the existing sensors in the network (see Figure 3), we optimize the placement of new sensors with the goal of filling blind spots. Our optimization target is an overall coverage increase and therefore a hardening against attacks.

 네트워크의 보안을 더 발전시키기 위해서, 우리는 네트워크 확장을 최적화하여 현재 지리적 분포를 최적화하기 위해 덜 커버된 지역에 새로운 센서들의 배포를 권장한다. 네트워크에 존재하는 센서들의 커버리지 정보를 기반으로, 우리는 사각지대를 채우는 것을 목표로 새로운 샌서들의 위치를 최적화한다.(그림 3 참고). 우리의 최적화 목표는 전반적인 커버리지의 증가이고 공격에 대한 강화이다.

 To provide an overview of areas that would benefit the most from the deployment of new sensors, we weight the need for better coverage according to the current sensor redundancy of the network. The lower the coverage, the higher is the demand for new sensors. We restrict possible locations to be on land. We further assume an average reception range of 400km and simplify the observable airspace to be a circle around the sensor. Figure 14 depicts areas according to their coverage increase for the entire network. While in Central Europe the deployment of new sensors does not significantly impact the overall resilience against attacks, new sensor setups close to the coastlines can greatly increase the attack resilience.

 새로운 센서들의 배포로 가장 큰 이득을 얻을 수 있는 영역에 대한 개요를 제공하기 위해서, 우리는 네트워크의 현재 센서 중복성에 따라 더 좋은 커버리지의 필요성에 무게를 둔다. 커버리지가 낮을 수록, 새로운 센서들에 대한 수요가 증가한다. 우리는 가능한 위치가 육지에 있도록 제한한다. 또한 평균 수신 범위가 400km이고 관측 가능한 공역이 센서 주의의 원으로 단순화한다. 그림 14는 전체 네트워크에 대한 커버리지 증가에 따른 영역을 보여준다. 중앙 유럽에서 새로운 센서들의 배포는 공격에 대한 전체적인 복원력에 영향을 주지 않는 반면에, 해안선에 가깝게 설치한 새로운 센서는 공격 복원력을 상당히 증가시킬 수 있다.

7. Extensions

 We discuss three extensions of our trust system with the goal of better reflecting real-world characteristics as well as introducing sensor reputation to weight their impact on the trust assessment process. Further, dynamic learning strategies can keep attack detection strategies updated.

우리는 실제 특성을 더 잘 반영하고 센서 평판을 도입함으로써 신뢰 평가 절차에 그들의 영향에 가중치를 부여하는 것을 목표로 우리 시스템의 3가지 확장을 논의한다. 또한 동적 학습 전략은 공격 탐지 전략이 계속 업데이트 되도록 한다.

Time Dependence. Since ADS-B broadcasts use the wireless medium, message collisions can occur when the frequency band is saturated. The resulting rate of message loss is dependent on the airspace density which in turn changes over time based on the operating hours of airports. The more aircraft share the same medium, the higher the chances are of messages being lost. While our current system estimates reception probabilities based on averaged one-day observations, a future extension of our trust system may account for time-dependent message loss.

ADS-B 방송이 무선 매체를 사용하기 때문에, 주파수 대역이 포화될 때 메시지 충돌이 발생할 수 있다. 메시지 손실률은 영공 밀도에 따라 달라지며, 이는 공항의 운영 시간에 기반하여 시간이 지남에 따라 변화한다. 항공기가 동일한 매체를 공유할 수록, 메시지들이 손실될 가능성이 높다. 우리의 현재 시스템이 평균 하루 관찰을 기반으로 수신 확률을 추정하지만, 우리 신뢰 시스템의 향후 확장은 시간에 따라 메시지 손실이 발생할 수 있다.

Sensor Reputation. In the currently deployed crowdsourcing network, we consider each sensor as equivalent to any other sensor. To refine this assumption, sensors may be assigned a reputation rating. A portion of the sensors are operated by personal contacts or registered users. Those sensors are expected to be less likely to participate in active attacks and we could link the reputation of the operator to possessed sensors. Furthermore, the hardware implementation could also be taken into account, where some implementations are more robust to defects than others. By incorporating sensor reputation, the validity of telling normal behavior and attack scenarios apart could be further improved.

현재 배포된 크라우드 소싱 네트워크에서는 각 센서를 다른 센서와 동등한 것으로 간주한다. 이러한 가정을 개선하기 위해서, 센서들은 평판 등급이 할당될 수 있다. 센서들의 일부는 개인 연락처 또는 등록된 사용자에 의해서 수행될 수 있다. 이러한 센서들은 활성화된 공격들에 참가하지 않을 것으로 예상되고 운영자의 평판을 보유한 센서들에 연결할 수 있다. 또한, 일부 구현들이 다른 구현보다 결함에 더 강한 하드웨어 구현도 고려할 수 있다. 센서 평판을 통합함으로써, 정상 행동과 공격 시나리오를 구분하는 것의 유효성을 더욱 향상시킬 수 있다.

Dynamic Learning. Finally, we envision the implementation of dynamic learning techniques. A dynamic learning approach could constantly update the trained message reception patterns. This allows to incorporate shifts which can occur when, e.g., sensors are joining or leaving the network, the reception range of sensors changes, or transmission ranges are altered. Moreover, new attack vectors may arise in the future. A (re-)training of our classifiers with updated attack vector definitions ensures that the trust evaluation process keeps its validity when facing currently unknown attacks.

마지막으로, 우리는 동적 학습 기술들의 구현을 구상한다. 동적 학습 방식은 학습된 메시지 수신 패턴들을 지속적으로 업데이트할 수 있다. 이것은 센서들이 네트워크에 가입하거나 떠나거나, 센서의 수신 범위가 변경되거나, 전송 범위가 변경될 때 발생할 수 있는 변화를 통합할 수 있게 한다. 또한 향후 새로운 공격 벡터가 발생할 수 있다. 업데이트된 공격 벡터 정의로 분류기를 (재)교육하면 현재 알려지지 않은 직면했을 때 신뢰 평가 프로세스의 유효성을 유지할 수 있다.

Related Work

 This paper is partly based on the work by Raya et al. who were the first to propose a framework for data-centric trust establishment with a focus on short-lived associations in volatile environments and on resulting work approaching distributed sensor events. While our proposal for trust establishment specifically targets ADS-B based air-traffic surveillance, similar trust requirements exist in Vehicular AdHoc Networks(VAHETs) or industrial wireless sensor networks. While Petit et al. discuss detection systems for VANETs based on dynamic thresholds, Ruj et al. focus on validating message consistency to identify misbehavior. Whereas Sun et al. present a trust framework to detect faulty data in VANETs, Hundman et al. apply similar data verification schemes for spacecraft. Dastner et al. classify military aircraft based on their ADS-B report trace. Wang et al. analyzes the feasibility of false data filtering in general sensor networks and Henningsen et al. especially focus on industrial networks. In comparison, our system is tailored towards a network of geographically distributed sensors.

 이 논문은 변동성이 큰 환경에서의 단명한 연관성과 그 결과로 발생하는 분산형 센서 이벤트에 접근하는 작업에 초점을 맞춘 데이터 중심 신뢰 구축 프레임워크를 최초로 제안한 Raya 등의 연구를 부분적으로 기반으로 한다. 신뢰 구축에 대한 제안은 특히 ADS-B 기반 항공 교통 감시를 대상으로 하지만, 차량용 애드혹 네트웍스(VAHET) 또는 산업용 무선 센서 네트워크에서도 유사한 신뢰 요구 사항이 존재한다. Petit 등은 동적 임계값을 기반으로 한 VANET의 탐지 시스템에 대해 논의하는 반면, Ruj 등은 잘못된 행동을 식별하기 위한 메시지 일관성을 검증하는 데 중점을 둔다. Sun 등은 VANET의 결함 있는 데이터를 탐지하기 위한 신뢰 프레임워크를 제시하는 반면, Hundman 등은 우주선에 대해 유사한 데이터 검증 체계를 적용한다. Dastner 등은 ADS-B 보고서 추적을 기반으로 군용기를 분류한다. Wang 등은 일반 센서 네트워크에서 허위 데이터 필터링의 가능성을 분석하고 Henningsen 등은 특히 산업 네트워크에 초점을 맞춘다. 이에 비해 우리의 시스템은 지리적으로 분산된 센서 네트워크에 맞게 조정된다.

 While in practice still vulnerable, the insecurity of ADS-B has long been highlighted from an academic perspective. Purton et al. analyzed critical information flows and focused primarily on techincal solutions. They applied a qualitative assessment method that identified potential shortcomings. In contrast, McCallie et al. applied a risk analysis to assess the impact of different attack vectors and recommended solutions to be incorporated into the ADS-B implementation plan. Moreover, Strohmeier et al. provide an overview of system-inherent problems and illustrate the security challenges of ADS-B in future air-traffic monitoring. Smith et al. empirically analyze pilots' reactions to wireless attacks on avionic systems and show that undetected attacks can lead to dangerous distractions. There are several open attacking ADS-B on different levels. Chevrot et al. present a framework for arbitrary false data injection and outline detection strategies. Nevertheless, we must always consider the necessary effort for an attack and its feasibility in a real-world scenario.

 실제로는 여전히 취약하지만 ADS-B의 불안정성은 오랫동안 학계의 관점에서 강조되어 왔다. Purton et al. 는 중요한 정보 흐름을 분석하고 주로 기술적 솔루션에 초점을 맞췄다. 그들은 잠재적 단점을 식별하는 정성적 평가 방법을 적용했다. 반면, McCallie et al. 는 위험 분석을 적용하여 다양한 공격 벡터의 영향을 평가하고 ADS-B 구현 계획에 통합할 솔루션을 권장했다. 또한 Strohmeier et al. 은 시스템 고유의 문제에 대한 개요를 제공하고 향후 항공 교통 모니터링에서 ADS-B의 보안 과제를 설명한다. Smith et al. 는 항공 전자 시스템에 대한 무선 공격에 대한 조종사의 반응을 경험적으로 분석하고 탐지되지 않은 공격이 위험한 주의 분산으로 이어질 수 있음을 보여준다. 다양한 수준에서 ADS-B를 공격하는 여러 가지 공개 공격이 있다. Chevrot et al. 은 임의의 허위 데이터 주입을 위한 프레임워크를 제시하고 탐지 전략을 개요화한다. 그럼에도 불구하고 우리는 항상 실제 시나리오에서 공격에 필요한 노력과 그 실현 가능성을 고려해야 한다.

 Moser et al. take a perspective on the feasibility of attacking ADS-B communication and consider an attacker using a multi-device setup. Recent work showed that such strong adversaries become increasingly realistic. Furthermore, Costin and Francillon demonstrated that the step from a scientific attack concept to a real attack is not necessarily too wide and managed to inject fake aircraft messages into live surveillance monitors. Later, Schafer et al. experimentally analyzed the practicability of known threats revealing startling results. In particular, aircraft instrument landing systems are prone to wireless attacks. Besides these works, which all focus on aviation applications, Balduzzi et al. proved that also maritime traffic via Automatic Identification System (AIS) broadcast messages can be the target of successful attacks. While the physical constraints of vehicles differ a lot, the similarity of communication channels helps to map well known attacks to this new context.

 Moser 등 은 ADS-B 통신 공격의 가능성에 대한 관점을 취하고 다중 장치 설정을 사용하는 공격자를 고려한다. 최근 연구에 따르면 이러한 강력한 공격자는 점점 더 현실적으로 변한다는 사실이 밝혀졌다. 또한 Costin과 Francillon은 과학적 공격 개념에서 실제 공격으로의 단계가 반드시 너무 넓지는 않으며, 실제 감시 모니터에 가짜 항공기 메시지를 주입하는 데 성공했음을 입증했다. 이후 Schafer et 등 은 알려진 위협의 실용성을 실험적으로 분석하여 놀라운 결과를 공개했다. 특히 항공기 계기판 착륙 시스템은 무선 공격에 취약하다. 항공 애플리케이션에 초점을 맞춘 이러한 연구 외에도 Balduzzi 등은 자동 식별 시스템(AIS) 방송 메시지를 통한 해상 교통도 성공적인 공격의 대상이 될 수 있음을 입증했다. 차량의 물리적 제약은 많이 다르지만, 통신 채널의 유사성은 잘 알려진 공격을 이 새로운 맥락에 매핑하는 데 도움이 된다.

 Besides the large body of offensive work, defensive proposals exist in recent research. Strohmeier et al. survey the existing research on countermeasures. More specifically, Ghose and Lazos as well as Schafer et al. and Liu et al. propose the usage of timing or Doppler shift characteristics to detect attacks on ADS-B. While this cannot protect from attacks, it still helps to identify malicious or inaccurate messages. Other location verification schemes and anomaly detection methods are based on RADAR observations, statistical tests, or PHY layer information. Habler and Shabtai use flight route modelling and anomaly detection to identify malicious ADS-B messages, achieving a false alarm rate of 4.5 %. Similar false alarm rates are achieved by Naganawa et al. based on Angle of Arrival (AoA) measurements. Sun et al. also use AoA verification but with a single receiver.

 공격적인 작업 외에도 최근 연구에서는 방어적인 제안이 존재한다. Strohmeier 등은 대응 방안에 대한 기존 연구를 조사한다. 보다 구체적으로, Ghose와 Lazos, Schafer 등과 Liu 등은 ADS-B에 대한 공격을 감지하기 위해 타이밍 또는 도플러 시프트 특성을 사용할 것을 제안한다. 이는 공격으로부터 보호할 수는 없지만 여전히 악의적이거나 부정확한 메시지를 식별하는 데 도움이 된다. 기타 위치 확인 체계와 이상 탐지 방법은 레이더 관찰, 통계 테스트 또는 PHY 계층 정보를 기반으로 한다. Habler 와 Shabtai는 비행 경로 모델링과 이상 탐지를 사용하여 악의적인 ADS-B 메시지를 식별하여 4.5%의 허위 경보율을 달성한다. 도착 각도(AoA) 측정을 기반으로 Naganawa 등 에서도 유사한 허위 경보율을 달성한다. Sun 등 도 AoA 인증을 사용하지만 단일 수신기와 함께 사용합니다.

 First results based on cross-referencing within a distributed sensor network are illustrated by Strohmeier et al. Oligeri et al. use IRIDIUM signals to validate GNSS position solutions. While Wesson et al. discuss solutions based on cryptography, Kim et al. evaluate a solution based on protocol extension with timestamps. Our system, on the other hand, requires no additional measurement information different from already collected data and can thus be implemented without any modifications.

 분산 센서 네트워크 내의 상호 참조를 기반으로 한 첫 번째 결과는 Strohmeier 등에 의해 설명된다. Oligeri 등은 이리듐 신호를 사용하여 GNSS 위치 솔루션을 검증한다. Wesson 등은 암호화 기반 솔루션을 논의하는 동안, Kim 등은 타임스탬프가 있는 프로토콜 확장을 기반으로 솔루션을 평가한다. 반면에 우리 시스템은 이미 수집된 데이터와 다른 추가 측정 정보가 필요하지 않으므로 수정 없이 구현할 수 있다.

 Aside from ADS-B and AIS, the insecurity of GPS has been repeatedly demonstrated, while Humphreys et al. were the first to publish an attack on GPS, where they managed to spoof GPS signals. Tippenhauer et al. later analyzed the requirements of successful GPS spoofing attacks and reasoned about possible attacker positions when facing a specific sensor deployment. Zeng et al. demonstrate the insecurity of road navigation systems via a stealthy manipulation based on GPS spoofing. Considering multiple sensors, countermeasures exist for the detection of GPS spoofing attacks and also for spoofer localization. However, these countermeasures depend on ground-based sensors and do not exploit the network volatility. This limits the impact and consequences to a fraction of real-world use cases.

 ADS-B 및 AIS 외에도 GPS의 불안정성은 다음과 같다. Humphreys 등은 GPS에 대한 공격을 최초로 게시하여 관리하는 동안 반복적으로 시연되었습니다. GPS 신호 스푸핑하기. Tippenhauer 등은 나중에 성공적인 GPS 스푸핑 공격의 요구 사항을 분석하고 특정 센서 배포에 직면했을 때 발생할 수 있는 공격자 위치를 추론했다. Zeng 등은 GPS 스푸핑을 기반으로 한 은밀한 조작을 통해 도로 내비게이션 시스템의 불안정성을 입증했다. 여러 센서를 고려할 때 GPS 스푸핑 공격 탐지와 스푸퍼 로컬라이제이션에 대한 대응책도 존재한다. 그러나 이러한 대응책은 지상 기반 센서에 의존하며 네트워크 변동성을 악용하지 않는다. 이로 인해 영향과 결과는 실제 사용 사례의 일부로 제한된다.

 Overall, we experience a gap between scientifically proposed defenses and deployed countermeasures. As a consequence, protecting ADS-B is an open challenge that demands scientific advances to consider the requirements and limitations of the real world.

 전반적으로 우리는 과학적으로 제안된 방어와 배포된 대응 조치 사이에 괴리가 발생한다. 결과적으로 ADS-B를 보호하는 것은 현실 세계의 요구 사항과 한계를 고려한 과학적 발전을 요구하는 미해결 과제이다.

Conclusion

This work approached a trust evaluation system for ADS-B based air-traffic surveillance using an already existing infrastructure of crowdsourcing sensors. We demonstrated how our solution leverages sensor redundancy to establish wireless witnessing to protect an otherwise unsecured open system. To this end, we tested our system against prominent attack vectors showing that we cannot only detect them but also draw conclusions about their type and the participating sensors. The validity of our trust evaluation depends on the redundancy of sensors observing same airspace segments. Moreover, we outlined considerations for future sensor deployment hardening the network’s security by optimized expansions.

이 작업은 이미 존재하는 크라우드 소싱 센서들의 인프라를 사용하여 ADS-B 기반의 항공 교통 관제에 대한 신뢰 평가 시스템에 접근했다. 우리는 솔루션이 센서 중복성을 활용하여 보안이 확보되지 않은 개방형 시스템을 보호하기 위해 무선 증인을 설정하는 방법을 시연했다. 이를 위해 저명한 공격 벡터에 대해 시스템을 테스트하여 탐지할 수 있을 뿐만 아니라 유형과 참여 센서에 대한 결론을 도출할 수 있음을 보여주었다. 신뢰 평가의 유효성은 동일한 공역 세그먼트를 관찰하는 센서의 중복성에 따라 달라진다. 또한 향후 최적화된 확장을 통해 네트워크의 보안을 강화하기 위한 고려 사항을 요약했다.

출처 및 인용

https://www.researchgate.net/profile/Nian-Xue/publication/349522456_Trust_the_Crowd_Wireless_Witnessing_to_Detect_Attacks_on_ADS-B-Based_Air-Traffic_Surveillance/links/6034f2bc299bf1cc26e5085b/Trust-the-Crowd-Wireless-Witnessing-to-Detect-Attacks-on-ADS-B-Based-Air-Traffic-Surveillance.pdf

Jansen, K., Niu, L., Xue, N., Martinovic, I., & Pöpper, C. (2021, February). Trust the Crowd: Wireless Witnessing to Detect Attacks on ADS-B-Based Air-Traffic Surveillance. In NDSS.

Contents

• SOLID 설계 원칙

Introduction to SOLID Principles

Introduction to SOLID

• 객체지향 소프트웨어를 견고하고 확장 가능하게 설계 하기 위한 다섯가지 기본 원칙

• SRP : 단일 책임 원칙

• OCP : 개방-폐쇄 원칙

• LSP : 리스코프 치환 원칙

• ISP : 인터페이스 분리 원칙

• DIP : 의존성 역전 원칙

Single Responsiblility Principle (SRP)

SRP

모든 클래스는 단 하나의 책임만을 가져야한다.

• 책임 : 객체가 "해야하는 것" 또는 "할 수 있는 것" (기능과 관련)

• 즉, 하나의 클래스는 하나의 기능만을 담당하여 하나의 책임을 수행하는데 집중

SRP가 지켜지지 않으면 "변경"에 취약

• 예측하지 못한 변경사항이 발생하더라도 유연하고 확장성 있게 시스템 구조를 설계 해야함 (유지보수 성을 높이기 위함)

책임 분리

• 한 클래스에서 너무 많은 책임을 부여하지 말고 단 하나의 책임만 수행하도록 변경하는 것

Open-Closed Principle (OCP)

OCP

확장에는 열려있어야 하며, 수정에는 닫혀있어야 한다.

• 확장에 열림 => 변경 사항이 발생했을 때 기존의 코드를 유연하게 확장할 수 있어야 함

• 수정에 닫힘 => 이때, 기존의 코드에는 수정이 없어야 함

• 추상화를 통해 상속 및 다형성 구조를 잘 마련해 두면 OCP를 손쉽게 따라갈 수 있음

• 일반적으로 추상 클래스와 상속을 통한 클래스 관계 구축을 통해 OCP를 따름

Liskov Substitution Principle (LSP)

LSP

상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

• 이를 위해서는 자식 클래스가 부모 클래스의 행동 규약을 지켜야함
• 다형성에 관련된 원칙!

void myData() {
    Collection data = new LinkedList();
    data = new HashSet();

    modify(data);

void modify(Collection data) {
    data.add(1);
    ...
}

data에 하위 클래스의 객체가 주어져도 modify 함수는 정상적으로 동작해야 한다.

LSP가 지켜지지 않은 예시 - Overriding 오류

class Animal {
    int speed = 100;

    int go(int distance) {
        return speed * distance;
    }
}

class Eagle extends Anlmal {
    String go(int distance, boolean flying) {
        if (flying)
            return distance + "만큼 날아감";
        else
            return distance + "만큼 걸어감";
}

부모의 go 함수를 제대로 오버라이딩 하지 않으면 다형성이 작동되지 않음

LSP가 지켜지지 않은 예시 - 부모의 의도와 다른 Overriding

LSP가 지켜지지 않은 예시 - 잘못된 상속 관계 구성

• A 개발자가 상속 구조의 호환성을 위해 Fish에서 speak은 구현하되 의미없는 동작을 하게 함 (예외를 출력)
• B 개발자는 상속 구조를 보고 LSP에 입각해 위와 같이 list에서 사용을 했는데 예상치 못한 예외가 출력됨 (협력 시 상호 신뢰를 잃게 될 수 있음)

• 코드를 수정한다면 speak은 따로 빼서 필요한 클래스에서만 구현하게 상속 구조를 수정 B 개발자는 위 상속 구조를 보고 speak을 할 수 있는 객체만 리스트에 담을 수 있음 (LSP를 따른다면 Fish를 리스트에 포함시키지 않는 방향이 되어야 함)

  Interface Segregation Principle (ISP)

  ISP

  클라이언트가 사용하지 않는 메소드에 의존하지 않아야 한다.

• 인터페이스에 클라이언트가 필요한 메소드만 포함될 수 있도록 분리해야 한다
• 인터페이스를 각각 사용에 맞게 분리하여 인터페이스의 단일 책임을 강조

SRP vs ISP

• SRP는 클래스가 단일 책임을 갖도록 하는 원칙 (클래스 분리)
• ISP는 인터페이스의 단일 책을 강조 (인터페이스 분리)

Dependency Inversion Principle (DIP)

DIP

의존 관계는 변화하기 어렵거나 변화가 거의 없는 것과 맺어야 한다.

• 객체들이 서로 정보를 주고 받을 때 의존 관계가 형성됨

• 이때, 객체들은 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺는 것이 각 클래스간의 결합도를 낮출 수 있음

• 변하기 어려운 추상적인 것들을 표현하는 수단으로 추상클래스와 인터페이스가 있음

• DIP를 만족하려면 추상클래스 또는 인터페이스와 의존 관계를 맺도록 설계해야 함

Example

• 기존에는 고수준의 클래스가 저수준의 클래스에 직접적으로 의존하는 방식으로 구현되는 경우가 많았음
• DIP에서는 이를 깨고, 고수준 클래스와 저수준 클래스 둘 다 추상화에 의존해야함을 의미
• 기존의 의존 구도를 뒤집는 것을 역전(Inversion)이라고 표현

Contents

• State Machine Diagram
• Activity Diagram

State Machine Diagram

State Machine Diagram

상태(State)

• 시스템이나 객체는 보통 주어진 시점에 어떠한 상태(state)에 있음
• 상태에 변화를 줄 만한 이벤트가 발생하지 않으면 변하지 않으며, 이벤트가 발생하면 상태에 변경이 생길 수 있음

상태 머신 다이어그램 (상태 다이어그램)

• 시스템이나 객체의 상태가 어떤 오퍼레이션에 의해 어떻게 동적으로 변하는지를 표현한 것

상태 머신 다이어그램의 기본 구성 요소

• 상태 (State) 시스템이나 객체의 특정 상태를 나타냄 Rounded rectangle로 표현하고 text로 상태를 표현

• 전이 (Transition) 상태의 변경을 표현하는 것으로 화살표와 이벤트로 표기

상태 머신 다이어그램의 기본 구성 요소

• 초기(Initial) 및 최종(Final) 상태 초기 상태 : 시작하는 시점의 상태 (Filled black circle로 표현) 최종 상태 : 종료하는 시점의 상태 (circled dot으로 표현)

passive / active 상태(state)

• 특정 시점에서의 컨디션으로 passive / active로 분류됨 Doing state는 active임

• Doing state의 경우 상태 내부에 행위를 기술 할 수 있음 Notation : do/behavior

전이(Transition)

• 이전 상태(source)에서 다음 상태(target)로 변경 될 때 이를 유발(trigger)하는 조건이나 이벤트(event)를 간선에 표기

Notation : Trigger[Guard] / Action

• Trigger : 전이를 발생시키는 event
• Guard : transition을 permit 하거나 block하는 boolean condition
• Action : 전이 이후 수행되는 행위 (uninterruptible action)로, 상태 전이의 결과/효과로 볼 수 있음

Example

Internal behavior of state

• State 내부에서 발생할 수 있는 행위를 표현 (label/behavior) do/behavior entry/behavior : 해당 state가 active될 때 수행 exit/behavior : 해당 state가 inactive될 때 수행

Internal transition of state

• State 내에서 reaction을 유발하는 전이 (다른 상태로 이동은 없음) Self transition과는 다름 (self는 entry/exit behavior를 유발함)

Composite States

Example

Activity Diagram

활동 다이어그램

• 시스템 내에서 수행되는 작업이나 동작의 흐름을 시각적으로 표현 Advanced version of flow chart

활동 다이어그램의 기본 구성 요소

Example

Swimlane(스윔레인)

• 활동 다이어그램은 여러 클래스와 연관 될 수 있기 때문에, 클래스 별로 나우어서 활동 흐름을 표시할 때 사용

Example

신호 (Signal)

• 특정 조건 하에서 시작된은 활동을 신호라고 함

Loop를 표현하는 방법 - Plain notation

Loop를 표현하는 방법 - Loop Node

• Setup : loop의 초기 조건을 정의
• Test : loop가 계속 진행될 조건을 정의
• Body : test가 통과되면 수행하게될 활동

Loop를 표현하는 방법 - Extension region(확장 영역)

• Collection의 개별 entry의 대해서 반복적으로 수행 (for each)

Recap.

Behavior diagrams for dynamic modeling

• State machine diagram (상태 머신 다이어그램) 시스템이나 객체의 상태가 어떤 오퍼레이션에 의해 어떻게 동적으로 변하는지를 표현한 것

• Activity diagram (활동 다이어그램) 시스템 내에서 수행되는 작업이나 동작의 흐름을 시각적으로 표현한 것

Contents

• Combined Fragments in Sequence Diagram
• Branches and Loops
• Order and Concurrency
• Other Stuff

Combined Fragment

Combined Fragments in Sequence Diagram

• 시퀀스 다이어그램의 요소를 그룹화 하고 조건에 따른 실행 흐름을 시각화하기 위해 사용

Predefined types of operators

Branches and Loops

Alternative Interation

Usage of alt fragment

• 조건에 따라 다른 흐름을 표현해야 할 때 사용

Guard condition

• Square brackets []으로 표시 ([else]는 predefined 됨)

Usage of opt fragment

• 조건이 성립할 때만 수행 Else가 없는 If statement와 유사 (하나의 operand만 존재)

Usage of loop fragment

• 반복적으로 수행되는 sequence를 표현
• Usage: loop (min, max) of (min..max)
• Guard condition : Guard가 false가 될 때 loop가 종료

Usage of break fragment

• 예외처리와 비슷함 Guard condition 명시 해주어야 함

• Guard가 True라면...(= 예외가 발생한다) Break안의 operand가 수행 됨 break 실행 시, b-> c -> e 순으로 실행 됨

Order and Concurrency

Weak Order of Sequences

Usage of seq fragment

• Operands간의 weak sequence를 나타낼 때 사용
• Weak sequence? 다른 lifeline에서의 메시지들의 순서는 자유로우나, 하나의 lifeline에서의 메시지들의 경우 순서는 시간 축을 따름

seq fragment with mulitple operands

• Operand 내에서 이벤트들은 그 순서를 유지함
• 서로 다른 생명선(lifeline)에서 작동하고 동일한 operand 내에서 발생하지 않는 이벤트들은 어느 순서로든 발생

Usage of strict fragment

• 서로 다른 operand간 수선도 엄격히 제약하고자 할 때 사용 Operand 내부는 기본적으로 seq임.

Usage of par fragment

• 서로 다른 operand의 동시 수행 (concurrency)를 표현할 때 사용 Operand내의 순서는 유지되나, 서로 다른 operand내의 순서는 상관 없음

Atomic Interaction

Usage of critical fragment

• Critical region (atomic area)을 나타낸 것으로, 해당 영역 내에 있는 메시지들 사이에 region 밖의 다른 메시지들이 껴들 수 없음 아래 두 operand들은 병렬적으로 수행되나, c->d사이에 다른 메시지가 껴들 수 없다.

Ohter stuffs

Interaction Reference

Usage of ref fragment

• ref fragment를 통해 다른 sequence diagram을 가리키게 할 수 있다.

Usage of time constraints

• 메시지 전송, 수신 기간, duration 등의 제약을 표기할 수 있음

Recap.

Combined Fragments in Sequence diagram

• 시퀀스 다이어그램에서 요소를 그룹화 하고 조건에 따른 실행 흐름을 시각화하기 위해 사용
• Branches and loops alt, opt, loop, break
• Order and Concurrency seq, strict, par, critical
• Other stuff Interaction reference, Iteration over a collection, Time constraints