Bitfrost/lang-ko: Difference between revisions
m (+cat.security) |
m (fixing DIV anchors + cosmetics) |
||
Line 1: | Line 1: | ||
{{OLPC}} |
{{OLPC}} |
||
{{Translation | lang = ko | source = Bitfrost | version = 40528}} |
{{Translation | lang = ko | source = Bitfrost | version = 40528}} |
||
{{TOCright}} |
|||
* 공식 번역문이 아니므로 (No Official translation), 번역이 매끄럽지 않은 부분은 [[Bitfrost|원문]]을 참조하거나, 기타 추가적으로 번역이 요구되는 부분은 주저 없이 discussion page에 메시지를 남겨주세요. |
* 공식 번역문이 아니므로 (No Official translation), 번역이 매끄럽지 않은 부분은 [[Bitfrost|원문]]을 참조하거나, 기타 추가적으로 번역이 요구되는 부분은 주저 없이 discussion page에 메시지를 남겨주세요. |
||
* It's partial and NOT official translation. Refer to [[Bitfrost|Original]] for precise content. If anyone wants more translation, just leave a message on the discussion page. |
* It's partial and NOT official translation. Refer to [[Bitfrost|Original]] for precise content. If anyone wants more translation, just leave a message on the discussion page. |
||
<div id="Introduction and summary"></div> |
|||
== Introduction and summary == |
|||
1971년, AT&T 프로그래머 Ken Thompson과 Dennis Ritchie는 UNIX 첫 버전을 공개했습니다. 이 운영시스템은 1969년 자금지원없이 UNICS라는 이름으로 진행된 프로젝트이며, 이 프로그래머들이 텍스트 처리 지원을 추가하겠다는 제안에 따라 벨 연구소로부터 자금지원을 받게 되며, 그 이름을 변경합니다. UNIX의 주요한 설계 아이디어는 오늘날까지도 이어집니다: Linux, FreeBSD와 같은 대중적인 서버 운영시스템과 다른 호스트들도 기본적인 UNIX 디자인 중 많은 부분을 공유하고 있습니다. |
1971년, AT&T 프로그래머 Ken Thompson과 Dennis Ritchie는 UNIX 첫 버전을 공개했습니다. 이 운영시스템은 1969년 자금지원없이 UNICS라는 이름으로 진행된 프로젝트이며, 이 프로그래머들이 텍스트 처리 지원을 추가하겠다는 제안에 따라 벨 연구소로부터 자금지원을 받게 되며, 그 이름을 변경합니다. UNIX의 주요한 설계 아이디어는 오늘날까지도 이어집니다: Linux, FreeBSD와 같은 대중적인 서버 운영시스템과 다른 호스트들도 기본적인 UNIX 디자인 중 많은 부분을 공유하고 있습니다. |
||
Line 111: | Line 115: | ||
| display = block }} |
| display = block }} |
||
<div id="The Bitfrost approach"/> |
<div id="The Bitfrost approach"></div> |
||
== Bitfrost 접근== |
== Bitfrost 접근== |
||
<div id=" |
<div id="Principles"></div> |
||
=== 원칙=== |
=== 원칙=== |
||
* 오픈 디자인 |
* 오픈 디자인 |
||
{{ Translated text | |
|||
* Open design |
|||
⚫ | |||
| display = block }} |
|||
No 록다운 |
* No 록다운 |
||
이 노트북의 보안 시스템은 디폴트로 사용자의 액션에 제한을 가하지만, 사용자에게 완전한 자유를 제공할 방법이 있어야 합니다. |
이 노트북의 보안 시스템은 디폴트로 사용자의 액션에 제한을 가하지만, 사용자에게 완전한 자유를 제공할 방법이 있어야 합니다. |
||
{{ Translated text | |
|||
* No lockdown |
|||
Though in their default settings, the laptop's security systems may impose |
|||
various prohibitions on the user's actions, there must exist a way for these |
|||
security systems to be disabled. When that is the case, the machine will |
|||
grant the user complete control. |
|||
| display = block }} |
|||
* No 메시지 읽기 |
* No 메시지 읽기 |
||
보안을 위해 사용자가 컴퓨터 메시지를 읽고 그에 따라 조치를 취하는데 의존해서는 안됩니다. 특정한 보안 메커니즘을 꺼는 것이 읽기를 요구할 "수도" 있지만, 머신이 글을 읽을 줄 모르는 사용자에게 주어지더라도 보안 문제가 없어야 합니다. |
보안을 위해 사용자가 컴퓨터 메시지를 읽고 그에 따라 조치를 취하는데 의존해서는 안됩니다. 특정한 보안 메커니즘을 꺼는 것이 읽기를 요구할 "수도" 있지만, 머신이 글을 읽을 줄 모르는 사용자에게 주어지더라도 보안 문제가 없어야 합니다. |
||
{{ Translated text | |
|||
* No reading required |
|||
Security cannot depend upon the user's ability to read a message from the |
|||
computer and act in an informed and sensible manner. While disabling a |
|||
particular security mechanism ''may'' require reading, a machine must be secure |
|||
out of the factory if given to a user who cannot yet read. |
|||
| display = block }} |
|||
*은밀한 보안 |
*은밀한 보안 |
||
가능하다면, 보안은 사용자의 주의를 끌지 않고 소리없이 작동하여야 합니다. |
가능하다면, 보안은 사용자의 주의를 끌지 않고 소리없이 작동하여야 합니다. |
||
{{ Translated text | |
{{ Translated text | |
||
⚫ | |||
* Unobtrusive security |
|||
; No lockdown : Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control. |
|||
Whenever possible, the security on the machines must be behind the scenes, |
|||
; No reading required : Security cannot depend upon the user's ability to read a message from the computer and act in an informed and sensible manner. While disabling a particular security mechanism ''may'' require reading, a machine must be secure out of the factory if given to a user who cannot yet read. |
|||
making its presence known only through subtle visual or audio cues, and never |
|||
; Unobtrusive security : Whenever possible, the security on the machines must be behind the scenes, making its presence known only through subtle visual or audio cues, and never getting in the user's way. Whenever in conflict with slight user convenience, strong unobtrusive security is to take precedence, though utmost care must be taken to ensure such allowances do not seriously or conspicuously reduce the usability of the machines. As an example, if a program is found attempting to violate a security setting, the user will not be prompted to permit the action; the action will simply be denied. If the user wishes to grant permission for such an action, she can do so through the graphical security center interface. |
|||
getting in the user's way. Whenever in conflict with slight user convenience, |
|||
strong unobtrusive security is to take precedence, though utmost care must be |
|||
taken to ensure such allowances do not seriously or conspicuously reduce the |
|||
usability of the machines. As an example, if a program is found attempting to |
|||
violate a security setting, the user will not be prompted to permit the action; |
|||
the action will simply be denied. If the user wishes to grant permission for |
|||
such an action, she can do so through the graphical security center interface. |
|||
| display = block }} |
| display = block }} |
||
<div id="Goals"/> |
<div id="Goals"></div> |
||
=== 목표=== |
=== 목표=== |
||
* 노 패스워드 |
* 노 패스워드 |
||
{{ Translated text | |
|||
* No user passwords |
|||
With users as young as 5 years old, the security of the laptop cannot depend |
|||
on the user's ability to remember a password. Users cannot be expected to |
|||
choose passwords when they first receive computers. |
|||
| display = block }} |
|||
* No 암호화된 인증절차 |
* No 암호화된 인증절차 |
||
{{ Translated text | |
|||
* No unencrypted authentication |
|||
Authentication of laptops or users will not depend upon identifiers that are |
|||
sent unencrypted over the network. This means no cleartext passwords of any |
|||
kind will be used in any OLPC protocol and Ethernet MAC addresses will never |
|||
be used for authentication. |
|||
| display = block }} |
|||
* 기본탑재된 보안 기능 |
* 기본탑재된 보안 기능 |
||
{{ Translated text | |
|||
* Out-of-the-box security |
|||
⚫ | |||
to download security updates when at all possible. |
|||
| display = block }} |
|||
* 제한된 기관 PKI |
* 제한된 기관 PKI |
||
이 노트북은 OLPC와 해당 국가 또는 지역 정부 (가령, 교육부)가 제공하는 퍼블릭 키와 더불어 제공되지만, 이 키들은 노트북 사용자를 식별하는데 사용되지 않습니다. 이 키들을 유일한 목적은 번들 소프트웨어들과 컨텐트의 통일성을 검증하기 위함입니다. 사용자들은 인증 절차없이 유기적으로 성장하는 PKI를 통해 식별됩니다. 즉, PKI에 대한 우리의 접근은 KCM, 핵심 지속성 관리입니다. |
이 노트북은 OLPC와 해당 국가 또는 지역 정부 (가령, 교육부)가 제공하는 퍼블릭 키와 더불어 제공되지만, 이 키들은 노트북 사용자를 식별하는데 사용되지 않습니다. 이 키들을 유일한 목적은 번들 소프트웨어들과 컨텐트의 통일성을 검증하기 위함입니다. 사용자들은 인증 절차없이 유기적으로 성장하는 PKI를 통해 식별됩니다. 즉, PKI에 대한 우리의 접근은 KCM, 핵심 지속성 관리입니다. |
||
{{ Translated text | |
|||
* Limited institutional PKI |
|||
The laptop will be supplied with public keys from OLPC and the country or |
|||
regional authority (e.g. the ministry or department of education), but these |
|||
keys will not be used to validate the identity of laptop users. The sole |
|||
purpose of these keys will be to verify the integrity of bundled software and |
|||
content. Users will be identified through an organically-grown PKI without a |
|||
certified chain of trust — in other words, our approach to PKI is KCM, or |
|||
key continuity management. |
|||
| display = block }} |
|||
* No 항구적 데이터 손실 |
* No 항구적 데이터 손실 |
||
{{ Translated text | |
{{ Translated text | |
||
; No user passwords : With users as young as 5 years old, the security of the laptop cannot depend on the user's ability to remember a password. Users cannot be expected to choose passwords when they first receive computers. |
|||
⚫ | |||
; No unencrypted authentication : Authentication of laptops or users will not depend upon identifiers that are sent unencrypted over the network. This means no cleartext passwords of any kind will be used in any OLPC protocol and Ethernet MAC addresses will never be used for authentication. |
|||
⚫ | |||
⚫ | |||
place so that the student can recover it in the event that the laptop is lost, |
|||
; Limited institutional PKI : The laptop will be supplied with public keys from OLPC and the country or regional authority (e.g. the ministry or department of education), but these keys will not be used to validate the identity of laptop users. The sole purpose of these keys will be to verify the integrity of bundled software and content. Users will be identified through an organically-grown PKI without a certified chain of trust — in other words, our approach to PKI is KCM, or key continuity management. |
|||
stolen or destroyed. |
|||
⚫ | |||
⚫ | |||
| display = block }} |
| display = block }} |
||
Revision as of 15:37, 5 June 2007
- 공식 번역문이 아니므로 (No Official translation), 번역이 매끄럽지 않은 부분은 원문을 참조하거나, 기타 추가적으로 번역이 요구되는 부분은 주저 없이 discussion page에 메시지를 남겨주세요.
- It's partial and NOT official translation. Refer to Original for precise content. If anyone wants more translation, just leave a message on the discussion page.
Introduction and summary
1971년, AT&T 프로그래머 Ken Thompson과 Dennis Ritchie는 UNIX 첫 버전을 공개했습니다. 이 운영시스템은 1969년 자금지원없이 UNICS라는 이름으로 진행된 프로젝트이며, 이 프로그래머들이 텍스트 처리 지원을 추가하겠다는 제안에 따라 벨 연구소로부터 자금지원을 받게 되며, 그 이름을 변경합니다. UNIX의 주요한 설계 아이디어는 오늘날까지도 이어집니다: Linux, FreeBSD와 같은 대중적인 서버 운영시스템과 다른 호스트들도 기본적인 UNIX 디자인 중 많은 부분을 공유하고 있습니다.
In 1971, AT&T programmers Ken Thompson and Dennis Ritchie released the first version of UNIX. The operating system, which started in 1969 as an unpaid project called UNICS, got a name change and some official funding by Bell Labs when the programmers offered to add text processing support. Many of the big design ideas behind UNIX persist to this day: popular server operating systems like Linux, FreeBSD, and a host of others all share much of the basic UNIX design.
1971년 유닉스 버전은 다음 보안 허가를 유저 파일에 지원하고 있습니다.
The 1971 version of UNIX supported the following security permissions on user files:
- non-owner can change file (write)
- non-owner can read file
- owner can change file (write)
- owner can read file
- file can be executed
- file is set-uid
이러한 허가는 친숙하게 보일텐데, 이것들은 오늘날에도 운영시스템에 따라 사용자가 자신의 파일을 설정하는 보안 허가와 매우 비슷합니다. 가장 큰 문제는, 이러한 허가들에 대해 믿기 힘들겠지만, 이것들이 사실상 사용자가 자신의 문서들에 대해 가진 유일한 실제 컨트롤 메커니즘인 점입니다: 사용자는 시스템 상의 다른 사용자들로부터 자신의 파일을 보호할 수 있지만, 그녀 자신의 프로그램들이 그녀의 파일들을 다루는 방식에 대해서는 어떤 통제도 할 수 없습니다.
These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, in her operating system of choice. What's deeply troubling — almost unbelievable — about these permissions is that they've remained virtually the only real control mechanism that a user has over her personal documents today: a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files.
1971년에는 별 문제가 없었습니다: 웹이 등장하기까지 20년이 지났으며, 대부분의 컴퓬터 사용자에 위협이 되는 모델은 오늘날 적용되는 것과 전혀 다릅니다. 그러나, 지난 35년간 방어 시스템이 변화가 없었다면, 우리가 바이러스와 악성 프로그램을 막을 수 없다는 것이 놀라운 일일까요?
In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can't stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?
문제의 핵심은 사용자를 위해 시스템 상에서 실행되는 모든 프로그램은 동일한 사용자를 위해 실행되는 다른 프로그램들과 똑 같은 능력과 허가를 가져야만 한다는 가정에 있습니다. 1971년에서 7년이 지난 뒤에야, 국제적인 패킷 교환 네트워크가 등장했습니다. 최초의 광역 TCP/IP 네트워크와 현대 인터넷에 의해 사용되는 커뮤니케이션 툴들은 1983년에서야 등장했는데, 이는 우리가 논의하는 Thompson과 Ritchie의 파일 허가 시스템으로부터 12년이 지난 뒤입니다. 1971년 당시에는, 계정 소유자 (사용자)가 물리적으로 특정 컴퓨터에 탑재하기 전에는 어떤 프로그램도 해당 컴퓨터에서 작동될 수 없었습니다 (가령, 펀치 테이프). 따라서, 당시에는 "전부 아니면 전무" 방식의 접근이 가능했는데, 실행되는 프로그램들은 그들 소유자의 계정에 대한 전적인 통제권을 가지는 것이 당연하게 여겨졌습니다: 사용자가 실행하는 모든 코드는 모든 실용적인 목적에서 신뢰를 받았습니다.
The crux of the problem lies in the assumption that any program executing on a system on the user's behalf should have the exact same abilities and permissions as any other program executing on behalf of the same user. 1971 was seven years before the first ever international packet-switched network came into existence. And the first wide-area network using TCP/IP, the communication suite used by the modern Internet, wasn't created until 1983, twelve years after Thompson and Ritchie designed the file permissions we're discussing. The bottom line is that in 1971, there was almost no conceivable way a program could "come to exist" on a computer except if the account owner — the user — physically transported it to a machine (for instance, on punched tape), or entered it there manually. And so the "all or nothing" security approach, where executing programs have full control over their owner's account, made quite a lot of sense: any code the user executed, she ipso facto trusted for all practical purposes.
오늘날, 이 상황은 크게 다를 수 없습니다: 가장 극명한 대조는 웹으로, 사용자는 그녀가 방문하는 모든 페이지에서 신뢰할 수 없는 스크립트를 실행하고 있습니다| 브라우저는 점점 더 복잡한 시스템이 되어가며, 그러한 웹 스크립트를 제한하려 하지만, 최신 버전마저도 자체의 스크립트 엔진 수행 상의 버그를 잡고 있는 실정입니다. 이메일로 잊지 마십시오: 누구나 실행가능한 프로그램을 보낼 수 있으며, 오랫동안, 사용자의 본능적 반응은 첨부 파일을 열고 프로그램을 실행하는 것입니다. 신뢰하지 못할 코드들이 사방에 늘려있고, 유일한 방어는 성가신 사용자 교육과 안티 바이러스 프로그램입니다; 후자는 사용자가 항상 최신 백신 프로그램을 가지고 있고, 백신 개발사는 최신 바이러스를 분석하고 백신을 제작할 충분한 시간이 있다는 가정 하에서만 제대로 작동합니다.
Fast forward to today, and the situation couldn't be more different: the starkest contrast is perhaps the Web, where a user's web browser executes untrusted scripting code on just about every web page she visits! Browsers are growing increasingly complex sandboxing systems that try to restrict the abilities of such web scripts, but even the latest browser versions are still fixing bugs in their scripting engine implementations. And don't forget e-mail: anyone can send a user an executable program, and for many years the users' instinctive reaction was to open the attachment and run the program. Untrusted code is everywhere, and the only defense seems to be tedious user training and anti-virus software — the latter assuming it's fully updated, and assuming the anti-virus makers have had time to deconstruct each latest virus and construct a defense for it.
Bitfrost 플랫폼을 구성하는 많은 기술과 접근법은 원래의 연구를 대변하지 않습니다: 그것들은 보안에 관한 서적에서 수년간 눈에 띄었으며, 일부는 현장에 적용되었고, 나머지는 연구실에서 시험 중입니다. XO 노트북의 독특한 점은, 수백만 혹은 수억 명의 사용자를 고려하여 그러한 보안 수단들이 하나의 시스템으로 통합되어 왔다는 점입니다. 이 노트북은 주류 컴퓨팅 프로그램들이 강력한 보안을 성취하기 위해 이전 프로그램들과의 호환성을 기꺼이 포기한 최초의 시도입니다. 예를 들면, 귀하는 Bitfrost 사양에서 안티 바이러스나 안티 스파이웨어 기술에 관한 논의가 전혀 없음을 보게 될 텐데, 이는 XO 노트북의 보안 플랫폼이 이러한 이슈들을 자유롭게 논의하고 있기 때문입니다.
Most technologies and approaches that constitute the Bitfrost platform do not represent original research: they have been known in the security literature for years, some of them have been deployed in the field, and others are being tested in the lab. What makes the OLPC XO laptops notable, however, is that they represent the first time that all these security measures have been carefully put together on a system slated to be introduced to tens or hundreds of millions of users. The laptops are also possibly the first time that a mainstream computing product has been willing to give up compatibility with legacy programs in order to achieve strong security. As an example, you'll find that talk about anti-virus and anti-spyware technology is conspicuously absent from the Bitfrost specification, because the security platform on the XO laptops largely renders these issues moot.
우리는 현재 시장에서 볼 수 있는 대부분의 주요 시스템들보다 극적으로 보다 안전하고, 극적으로 보다 유용한 보안 시스템을 창출하고 있습니다. 유용성에 관한 한 가지 성과는 사용자의 응답을 요구하는, 그러한 응답 마저도 '예 또는 아니오'로서 어린이도 쉽게 이해할 수 있는 단 하나의 보호만이 Bitfrost에 의해 제공되는 점입니다. 보안의 나머지 부분은 화면 아래에서 제공됩니다. 그러나, 보안과 유용성을 모두 성취하는 것은 힘든 과제이며, 우리가 "완벽한 보안"을 창출하지도, 창출했다고 믿지도 않는 점에 유의해 주십시오. 실제 세상에서 완전한 보안이라는 언명은 어리석은 일이며, 우리는 전혀 그러한 주장을 하지 않습니다.
We have set out to create a system that is both drastically more secure and provides drastically more usable security than any mainstream system currently on the market. One result of the dedication to usability is that there is only one protection provided by the Bitfrost platform that requires user response, and even then, it's a simple 'yes or no' question understandable even by young children. The remainder of the security is provided behind the scenes. But pushing the envelope on both security and usability is a tall order, and it's important to note that we have neither tried to create, nor do we believe we have created, a "perfectly secure" system. Notions of perfect security in the real world are foolish, and we distance ourselves up front from any such claims.
Bitfrost 접근
원칙
- 오픈 디자인
- No 록다운
이 노트북의 보안 시스템은 디폴트로 사용자의 액션에 제한을 가하지만, 사용자에게 완전한 자유를 제공할 방법이 있어야 합니다.
- No 메시지 읽기
보안을 위해 사용자가 컴퓨터 메시지를 읽고 그에 따라 조치를 취하는데 의존해서는 안됩니다. 특정한 보안 메커니즘을 꺼는 것이 읽기를 요구할 "수도" 있지만, 머신이 글을 읽을 줄 모르는 사용자에게 주어지더라도 보안 문제가 없어야 합니다.
- 은밀한 보안
가능하다면, 보안은 사용자의 주의를 끌지 않고 소리없이 작동하여야 합니다.
- Open design
- The laptop's security must not depend upon a secret design implemented in hardware or software.
- No lockdown
- Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control.
- No reading required
- Security cannot depend upon the user's ability to read a message from the computer and act in an informed and sensible manner. While disabling a particular security mechanism may require reading, a machine must be secure out of the factory if given to a user who cannot yet read.
- Unobtrusive security
- Whenever possible, the security on the machines must be behind the scenes, making its presence known only through subtle visual or audio cues, and never getting in the user's way. Whenever in conflict with slight user convenience, strong unobtrusive security is to take precedence, though utmost care must be taken to ensure such allowances do not seriously or conspicuously reduce the usability of the machines. As an example, if a program is found attempting to violate a security setting, the user will not be prompted to permit the action; the action will simply be denied. If the user wishes to grant permission for such an action, she can do so through the graphical security center interface.
목표
- 노 패스워드
- No 암호화된 인증절차
- 기본탑재된 보안 기능
- 제한된 기관 PKI
이 노트북은 OLPC와 해당 국가 또는 지역 정부 (가령, 교육부)가 제공하는 퍼블릭 키와 더불어 제공되지만, 이 키들은 노트북 사용자를 식별하는데 사용되지 않습니다. 이 키들을 유일한 목적은 번들 소프트웨어들과 컨텐트의 통일성을 검증하기 위함입니다. 사용자들은 인증 절차없이 유기적으로 성장하는 PKI를 통해 식별됩니다. 즉, PKI에 대한 우리의 접근은 KCM, 핵심 지속성 관리입니다.
- No 항구적 데이터 손실
- No user passwords
- With users as young as 5 years old, the security of the laptop cannot depend on the user's ability to remember a password. Users cannot be expected to choose passwords when they first receive computers.
- No unencrypted authentication
- Authentication of laptops or users will not depend upon identifiers that are sent unencrypted over the network. This means no cleartext passwords of any kind will be used in any OLPC protocol and Ethernet MAC addresses will never be used for authentication.
- Out-of-the-box security
- The laptop should be both usable and secure out-of-the-box, without the need to download security updates when at all possible.
- Limited institutional PKI
- The laptop will be supplied with public keys from OLPC and the country or regional authority (e.g. the ministry or department of education), but these keys will not be used to validate the identity of laptop users. The sole purpose of these keys will be to verify the integrity of bundled software and content. Users will be identified through an organically-grown PKI without a certified chain of trust — in other words, our approach to PKI is KCM, or key continuity management.
- No permanent data loss
Information on the laptop will be replicated to some centralized storage place so that the student can recover it in the event that the laptop is lost, stolen or destroyed.
관심있으면 OLPC security mailing list에 참여해 주십시오.
If this subject matter interests you, please read the complete Bitfrost specification, join the OLPC security mailing list, share your thoughts, and join the discussion.