Salted Hash 방법
hash값을 저장할 때 각자의 salt값을 가지고 hash를 만든다.
y=hash(pwd,s)를 저장하고 y값과 hash(pwd,s)를 비교한다.
-> salt를 하게 되면 비교의 경우의 수를 훨씬 크게 가져간다

Biometrics
식별(카메라 속 사람을 식별)하거나 인증(어딘가에 들어가기 위한 인증)을 위한 용도로 사용
– insult rate: 나를 나로 인증하지 못하는 경우 (모욕률)
– fraud rate: 나를 상대방으로 인식하는 경우 (기만율)
-equal error rate: 모욕률 = 기만율

Authorization
classification 문제: granularity(세밀성), aggregation(군집성)
L(o): object에 대한 보안 정도, L(s): subject에 대한 보안 정도
MLS: Access Control의 한 분야
1. Bell Lapadula
인가되지 않은 reading을 막음 (비밀성)
S can read O only if L(o) <= L(s) — 나보다 비밀성이 낮은 경우에만 읽을 수 있음
S can write O only if L(s) <= L(o) — 나보다 비밀성이 높은 경우에만 쓸 수 있음
2. Biba’s model
인가되지 않은 writing을 막음 (무결성)
S can write O only if I(o) <= I(s) — 나보다 무결성이 낮은 경우에만 쓸 수 있음
S can read O only if I(s) <= I(o) — 나보다 무결성이 높은 경우에만 읽을 수 있음

Multilateral Security
up and down만으로 security를 나타내기 힘들 때 사용

Covert Channel
Bob이 확인했을 때 파일(FileXYzW)이 있으면 1, 없으면 0

Inference Control
구체적인 정보는 일반적인 질문들에 의해서 유출될 수 있음
Query set size control: set size가 너무 작으면 응답하지 않음
Inference Control은 약해도 안 하는 것보다는 낫다

Capcha
컴퓨터는 통과 못하고 사람은 통과할 수 있는 것
(컴퓨터가 generate하고 test하지만 컴퓨터는 통과하지 못함)
–> visual based, audio based는 가능, text based는 불가

Replay Attack
Alice 자리에 Trudy를 넣어서 보안이 뚫림

IDS
Intrusion Detection
1. signature based(흔적 기반): 흔적을 정의해야 함 -> 공격자가 시그니저 설정법을 안다면 공격을 늦출 뿐임 -> 시그니처를 최신으로 업데이트하고 시그니처 수를 늘릴 필요가 있음
2. Anomaly based(이상치 기반): variation 안에 있을 때 Normal이라고 정의하자 (Normal Pattern 분석)

Challenge Response

Alice: 나 앨리스야
Bob: (challenge Response) – 그때그때 다름, Replay Attack이 불가능함, ex) random값인 Nonce
Alice: hash(Alice’s password, Nonce)
-> Nonce가 랜덤값이므로 Trudy는 Nonce에 대응되는 hash값을 알 수 없음
(Bob은 반드시 Alice의 password를 알고 있어야 됨)

<대칭키[K_AB]를 이용할 수도 있다>
Alice: 나 앨리스야
Bob: R
Alice: E(R, K_AB)
-> 그러나 Bob자리에 Trudy가 오면, Alice는 E값을 보냈을 때 Trudy한테 보내는지를 모름

그렇다면 Mutual Authentication을 하려면?

Alice: 나 앨리스야, R_a
Bob: R_b , E(R_a, K_AB)
Alice: E(R_b, K_AB­)
-> 둘 다 암호를 전송해서 인증하면 되지 않을까?

Trudy: 나 앨리스야, R_a
Bob: R_b , E(R_a, K_AB)
Trudy: R_b­
Bob: R_c, E(R_b, K­­_AB)
Trudy: E(R_b, K_AB­)
-> 이렇게 풀 수 있음

Alice: 나 앨리스야, R_a
Bob: R_b , E(“Bob”, R_a, K_AB)
Alice: E(“Alice”, R_b, K_AB­)
-> 이렇게 방향만 추가해도 Trudy는 같은 방식으로 못 품
(Trudy가 R­_b 보내봤자 Bob이 “BOB”을 이용한 암호를 보내므로 다시 못 보냄)

Public Key Authentication

1. Bob이 R을 Alice의 Public Key로 암호화하면, Alice가 R을 복호화해서 전송 (ok)
2. Bob이 R을 Bob의 Public Key로 암호화 -> Alice는 Bob의 Private Key를 몰라서 안 됨 (no)
3. Bob이 R을 Bob의 private key로 서명 -> Alice는 Bob의 public key로 복호화, 그러나 이것은 Trudy도 가능 (no)
1의 문제점: alice가 trudy인지 확인을 안 하기 때문에 mutual authentication이 안 됨

Session Key
이번 세션에만 사용할 수 있는 키

Alice: 나 앨리스야, R
Bob: {R,K}_alice // Alice의 공개키로 암호화해서 전송, K는 세션키
Alice: {R+1,K}_bob // bob의 공개키로 암호화해서 전송, K는 세션키
-> mutual authentication이 안 됨
(Bob 대신 Trudy가 Alice의 Public Key로 {R,K}_aclie를 보내면 됨)
-> 그럼 암호화 대신 서명을 하면 어떨까?

Alice: 나 앨리스야, R
Bob: [R,K]_bob // bob의 개인키로 서명해서 전송, K는 세션키
Alice: [R+1,K]_alice // Alice의 개인키로 서명해서 전송, K는 세션키
-> mutual authentication은 되지만, Trudy가 Public Key로 풀 수 있음
-> 서명하고 암호화하면 어떨까?

Alice: R
Bob: {[R,K]_bob}_alice // bob의 개인키로 서명 후 alice의 공개키로 암호화
Alice: {[R+1,K]_alice}_bob // Alice의 개인키로 서명 후 bob의 공개키로 암호화
-> Ok!

PFS와 Diffie-Hellman
Perfect Forward Secrecy (Trudy가 이후에 암호 해독이 불가능하게 함)
Trudy가 나중에 세션키를 알게 되더라도 문서를 보지 못하게 하는 것

세션키를 g­^abmod p로 사용함 -> 나중에 세션키를 알게 되더라도 해독 불가

Alice: E(g^amod p, K_AB)
Bob: E(g^bmod p, K_AB)
-> PFS를 제공할 수 있음, 다만 g^amod p는 일회성이여야만 함, 그냥 g­^amod p와 g^bmod p를 전송하면 안 됨? -> 중간자 공격당할 수도 있음!

Mutual Authen, sess Key, PFS

Alice: 나 앨리스야, R_A
Bob: R_b, [{R_A, g^bmod p}_alice]_bob
Alice: [{R_b, g­^amod p}­_bob]_alice

Timestamps
R대신에 Timestamps를 사용할 수 있다 -> 메시지 수를 줄일 수 있음!
Timestamps는 선암호, 후서명을 하면 문제점이 발생할 수 있음

Alice: 나 앨리스야, [{T,K}_bob]_alice
Trudy: 나 트루디야, [{T,K}_bob]_trudy
Bob: [{T+1,k}_trudy]_bob
-> Trudy는 위와 Alice의 공개키를 알기 때문에 중간에서 {T,K}_bob를 획득 가능
-> Bob이 Trudy에게 보내는 메시지를 보고 Alice-Bob의 세션키 K를 획득 가능
해결책: Bob이 응답할 때 K를 빼버리면 선암호를 사용해도 문제 없음!

Alice: 나 앨리스야, [{T,K}_bob]_alice
Bob: [{T+1}_alice]_bob
-> Ok!

Fiat-Shamir

Suppose N=pq, where p and q prime
Alice has a secret S
v=S² mod N

Alice: (secret S, random r) x=r² mod N
Bob: e (0 or 1)
Alice: y=r*S^e mod N
-> Bob은 y²이랑 x*v^e mod N이랑 비교해서 같으면 Alice인지 확인됨

Trudy가 개입하면 x=r²을 줘서 y=r을 얻음 (e=0일 때), x=r²*v^-1을 줘서 y=r을 얻음
-> 1/2 확률로 r을 얻을 수 있음

만약 e가 (0,1,2)라면?
-> 2/3 확률로 r을 얻을 수 있으므로 더 손해임

Kerberos
n명의 유저가 있어도 n개의 대칭키만 사용하는 방식

KDC는 각 사용자와 대칭키를 공유하고 있다.
K_KDC <- KDC만 알아야 되는 키
TGT: 티켓을 얻기 위한 티켓 // K_KDC­로 암호화 돼 있으므로 KDC만 알 수 있음

1. 로그인

Alice: hash(password)
Computer: K_A=hash(password)
KDC: E(S_A,TGT,K_A) // TGT = E(“Alice”,S_A, K_KDC)
-> computer get TGT, S_A

2. Bob으로 가는 티켓 얻고 접속

Alice: 밥이랑 이야기할래
Computer: TGT, Authenticator=E(timestamp,S_A)
KDC: E(“Bob”, K_AB, ticket to Bob, S_A) // ticket to Bob = E(“Alice”, K_AB, K_B)
-> computer get tiket to Bob, K_AB
Computer: tiket to Bob, Authenticator=E(timestamp,K_AB)
Bob: E(timestap+1,K_AB)