(20250808032)다중 도메인서버, 전자서명, PKI 폼,배열

DNS

 

다중 도메인 서버 구현

●  하나의 DNS서버에 여러 개의 도메인을 서비스한다.

● named.conf 파일에 각 도메인별 zone 항목을 추가한다.

●  각 zone에서 사용할 zone 파일을 추가한다.

●  서버를 재 시작한다.

 

 

네임서버에 도메인 2개를 올릴 수 있다. 두 도메인은 독립적이다.

 

 

 

=============================================

실습

 

 

ast12.itc. 추가해서 다중도메인 서버 구현해 보기

 

 

/etc/named.conf 파일에 ast12.itc. 존 항목 추가해 주기

 

zone "ast12.itc." {

      type master;

      file "ast12.itc.zone";

};

 

 

 

vi /var/named/ast12.itc.zone 파일 생성해 주기

 

 

systemctl restart named.service 후 확인

 

 

두 개 다 독립적으로 잘 돌아간다.

 

=============================================

 

호스트 항목의 목록들이 같으면 같은 존파일을 사용할 수도 있다.(ast12.sec와 ast12.itc가 같은 호스트 항목을 사용해서 ast12.itc를 안 만들고 ast12.sec 하나로 사용할 수 있다.)

ㄴ 하지만 이건 사용 안 하는 게 좋다. 언제 사고 날지 모름. 일단 됨.

 

 

---

암호학

프레임웤 = 미래에 무슨 일이 일어나기 전에 대비하기 위해서 문서를 미리 만들어두는 거

 

 

 

전자서명  - 사용자, 메시지를 인증해야 한다.

 

●  배경 종이 문서 사회에서 정보화 사회로의 진전으로 다양한 서비스 요구 데이터 무결성, 사용자 인증, 부인방지 서비스가 필수적

●  목적 신뢰성 확보 ( 내용의 위·변조 및 신분 확인에 사용)

●  1976년 Diffie와 Hellman에 의해 개념 제시

●  전자서명 = 사용자 인증 + 메시지 인증

 

구분	종이문서	전자문서
기록매체	종이	전자기록 매체
전달방법	우편,인편	네트워크를 통한 전송
안전, 신뢰성	위,변조가 비교적 어려움 종이의 물리적 특성으로 위,변조 식별 가능	위,변조가 용이함. 전자기록매체의 물리적 특성으로 위,변조 식별불가능
진정성 증명	수기서명, 날인	전자서명

 

 

■  전자문서의 문제점

• 위, 변조가 용이 : 무결성

• 문서작성 사실 입증 곤란 : 부인방지

 

■  전자상거래의 문제점

• 거래상대방의 신원확인 곤란 : 사용자 인증

• 전송 내용의 비밀 유지 곤란 : 기밀성(큰 문제는 아님)

ㄴ 무결성의 심각한 문제가 생긴다.

 

전자서명은 책임추적성을 어떻게 할 것이냐가 가장 중요함.

 

 

전자 서명의 이해

 

●   서명자 신원확인(User Authentication)

- 근원지 증명 개인키의 소유자가 전자서명 행위자임을 증명, 서명자 고유의 표식

 

●   위조 불가(Not forgeable)

- 합법적인 서명자 외에는 전자서명 생성 불가 증명

 

●   변경 불가(Unalterable)

- 서명한 문서의 내용과 서명의 변경 불가 증명

 

●  부인 불가(Non-Repudiation)

- 문서 만든 사람이 자기가 만든 거 아니라고 하면 안 됨. 서명은 본인 이외에는 불가능함을 증명

 

●  재사용 불가(Not Reuseable)

- 다른 전자문서의 서명으로 사용 불가능함을 증명

 

 

암호화 방법과 전자 서명

 

■   전자서명은 전자서명의 조건을 만족하면서 서명방식과 검증방식이 명확하여야 함

 

■   대칭키 암호 알고리즘에 의한 방법(지금은 사용 안 함.)

• 중재된 서명기법

• 서명과 검증을 제삼자에 의해서 행할 수밖에 없음

 

■   공개키 암호 알고리즘에 의한 방법(요즘이걸로 사용함.)(가이드라인이다.)

• 메시지 복원형 전자서명 방식

• 문서 자체를 이용하는 서명방식

• 메시지 부가형 전자서명 방식 - 우리가 주로 사용하는 방식.

• 문서에 서명메시지를 포함하는 방식

 

 

우리가 지금 사용하는 전자서명은 100 퍼 공개키를 사용한다.

모든 규정, 법률 안에는 가이드라인이 들어간다.

 

Standard : 반드시 지켜야 하는 규정
Guideline : Standard를 만들 때 같이 만드는 최소한의 원칙. 가이드라인을 따르지 않으면 직접 입증해야 하지만 쓰면 입증할 필요가 없음

 

 

공개키를 이용한 전자서명

■  전자서명과 공개키 암호의 관계

■  전자서명의 인감증명 역할 → ‘공개키’

■  서명자 A가 갖고 있는 인감 → ‘개인키’

■  전자서명

• 서명자 A의 개인키로 데이터의 전자서명을 생성(인감증명서.)

• 서명자 A의 공개키로 전자서명을 검증 -(인감도장)

 

 

 

 

메시지를 보낼 때 그냥 일단 메시지를 보낸다. 

송신자가 보냈다는 것을 확인하기 위해 메시지에 해쉬함수를 넣고, 다이제스트를 만듭니다. 

만든 다이제스트를 송신자의 개인키로 암호화하고(서명), 아까 그냥 보낸 메시지와 합쳐서 수신자에게 날립니다.(부가용 전자서명)

수신자는 받은 메시지와 서명을 분리시킨 후, 서명은 송신자의 공개키로 암호화를 풀고, 메시지는 해쉬함수에 넣어서 나온 다이제스트를 서명에서 암호화를 푼 다이제스트랑 비교를 한 후 같은지 확인하고 같으면 신원이 증명이 됩니다.

 

공개키에는 어떤 해쉬코드를 사용할 것인지 정해져 있습니다.

 

이 방식을 사용하면 메시지를 아무나 볼 수 있기 때문에 기밀성이 확보되지 않아서 전자봉투 알고리즘을 사용해서 문제를 해결합니다.

두 개 다 다른 프로그램이기 때문에 같이 사용하면 됩니다.

 

 

전자 봉투

• 서명과 기밀을 동시에 이용

• 암호는 대칭키를 이용하고 대칭키는 공개키로 암호화한다.

• 속도가 빠름

 

메시지를 두고 송신자가 비밀키로 사용할 길이가 정해진 난수를 생성합니다.

송신자가 비밀키로 암호화한 메시지(암호 메시지), 수신자의 공개키로 암호화한 비밀키(전자봉투)를 같이 보냅니다.

그럼 수신자는 암호 메시지와, 전자봉투를 분리해 전자봉투를 수신자의 개인키를 통해 복호화하고, 거기서 나온 비밀키를 통해 암호메시지를 복호화합니다.

 

여기서 인수는 수신자의 공개키, 송신자의 메시지입니다.

 

 

 

PKI

PKI구성 요소

 

■  인증서는 인감증명서에 해당

• 기밀성, 무결성, 인증

 

■  공개키의 소유자를 증명

 

 

인증서

 

인증서의 정의

■  공개키의 소유자를 증명

■  인증서라 함은 개인키와 이에 합치하는 공개키에 대하여 이를 소유하는 자연인 또는 법인 과의 귀속관계 등을 인증기관이 자신의 개인키로 전자서명하여 확인, 증명하는 전자적 정보

ㄴ 여러 가지 정보가 다 들어가 있다.

 

인증서는 인증기관에서 발행하고, 인증기관 자신들의 개인키로 암호화해뒀다.

 

 

X.509

■  1K 바이트 정도의 바이너리 데이터

■  RFC 2459(X.509 ver. 3)

■  인증서 항목

• 서명 전 인증서

      - tbsCertificate(to be signed certificate)

      - 확장항목 이외의 항목 필수

• 서명 알고리즘

      - 메시지 다이제스트 알고리즘(MD2, MD5..)

      - 공개키 암호 알고리즘

• 인증기관

      - 서명 전 인증서 부분을 입력으로 해서 서명

      - 인증기관의 개인키와 인증서로 기재한 알고리즘 이용

 

 

 

인증서 발행과 이용

 

■  인증서를 발행하기 위해서는 공개키의 소유주는 인증기관에 공개키를 등록하고 인증기관은 등록된 개인의 공개키를 자신의 개인키로 서명해서 인증서를 발행함.

 

인증기관 → 인증서를 발행하는 기관

 

 

인증 기관과 CRL

■ Root CA : 한국정보보호진흥원

■  CA (Certificate Authority) : 인증서 발행기관

■  RA (Registration Authorities) : 인증서 유저 등록 기관(여기서도 인증서 발행할 수 있다.)

 

인증서는 인증기관에서 발행해야 하는데 직접 못 가니까 인증기관 산하에 있는 등록기관에서 인증서를 발급받을 수 있다

 

 

CRL (Certificate Revocation List) : 인증서 폐지 목록

 

만약 개인키가 유출당하면 인증서를 새로 발급받아야 한다.

기존의 인증서는 폐기되고 CRL로 넘어가고, CRL에 있는 인증서로 접근 요청이 들어오면 거절한다.

 

 

 

---

PHP

이중 for문

값 2개를 입력받아서 행, 열을 입력받아서 해당 행, 열만큼 생성하는 프로그램 작성.

 

실습

table.html

<html>
 <head>
 <title>테이블 만들기 폼</title>
 <meta http-equiv="content-type" content="text/html; charset=utf-8">
 </head>
  <form method="post" action="table.php">
    행을 입력하세요 : <input type="text" name="num1"><br>
    열을 입력하세요 : <input type="text" name="num2"><br>
    <input type="submit" name="확인" value="확인">
    <input type="reset" name="취소" value="취소"><br>
 </form>
 </html>

 

table.php

<?
$num1 = $_POST["num1"]; //행 세로
$num2 = $_POST["num2"]; //열 가로

echo("<table>");
$n = 1;
for($i=0; $i<$num1; $i++){
echo("     <tr>
          </tr>");
echo("<tr>");
for($j=1; $j<=$num2; $j++){
echo("<td>$n</td>");
$n++;
}
echo("</tr>");
}
echo("<table>");
?>
<hr><p>
<? show_source(__FILE__); ?>

 

 

폼 

html에서 입력받을 수 있는 유일한 값

 

우리가 사용하는 것은 post, get방식

html은 상태정보를 저장하지 않습니다. 그래서 값을 무조건 전달해주어야 하는데,

html끼리 보낼 때는 get방식을 보통 사용하고, html이 프로그램으로 값을 보낼 때는 get, post방식을 둘 다 사용합니다.

중요한 정보는 세션에 저장을 합니다. 세션은 서버 쪽에 저장이 됩니다. 그리고 세션은 하드드라이브에 저장이 되기 때문에 속도가 느릴 수  있습니다.

 

 

배열

- 여러 개의 변수를 모아서 정의하는 것

 

php에서 배열을 사용하는 이유 = 변수를 많이 사용해야 하는데, 이름을 정하는 것이 귀찮을 때 사용합니다.

 

 

1차원 배열 = 가장기본적인 배열구조

 

 

key = 첨자

value = 값

 

키 값에 문자를 사용하는 것은 연관배열이라고 합니다.

 

예)

$row [sno] = 'S01009';

$row [sname] = '관우';

$row [syear] = 4;

 

 

array()는 배열을 생성하는 함수

 

$ar1 = array(1,2,3);

밑에랑 같은 의미

$ar1 [0] = 1;

$ar1 [1] = 2;

$ar1 [2] = 3;

 

$ar2 = array(3 => "abc", 4 => "def", "ghi");

밑에랑 같은 의미

$ar2 [3] = ‘abc’;

$ar2 [4] = ‘def’;

$ar2 [5] = ‘ghi’;

 

$ar3 = array("a" => "ab", "k" => "a2", 0 => 23);

밑에랑 같은 의미

$ar3 [a] = ‘ab’;

$ar3 [k] = ‘a2’;

$ar3 [0] = ‘23’;

 

php는 첨자에 규칙이 없다